核心业务系统目标功能概要文档格式.docx
《核心业务系统目标功能概要文档格式.docx》由会员分享，可在线阅读，更多相关《核心业务系统目标功能概要文档格式.docx（12页珍藏版）》请在冰点文库上搜索。
1.1.3帐户管理
帐户管理需求包括：
❑将帐户号与一组灵活定义的必须录入的信息进行关连，包括：
对应帐户存款，客户ID，校验位
❑账户余额能够通过各种交易渠道得到实时更新，并且余额对银行外部用户的显示是一致的，无论他们是使用电话、互联网还是纸质通知获得余额数字
❑系统能够灵活定义账户的维护规则，无论是在账户类别的基础上，还是在个别账户的基础上
❑严格控制账户的状态变更的操作。
依据账户状态系统可以将账户进行分组或进行分析
❑系统能够建立一种层次结构来进行账户限额的设定，例如，通过账户的客户属性、金融产品属性、所属的业务单元等，层层进行限额机制的设计
❑有一套严格而定义灵活的机制保证账户在创建、访问、状态变更时的安全性。
例如可以将账户密码安全的传递到所有者手中等。
❑有一套灵活的账户结构机制，可以将核心系统的账户信息和其它系统的账户，如资金、投资系统等，联系起来
❑能够累计存贷款利息，根据各种利息计算因素的变化，如到息日等进行自动重算
❑通过和第三方产品的集成，可以实现以电子化形式存储用户签名，已进行账户交易授权的机制。
∙与一个产品关连的所有帐户以建立运营的缺省规则（可以修改）
∙支持清算过的余额，待清算的余额，和累计清算的余额
∙帐户限制环境的层次结构（比如，按客户，帐户类型，产品，分行，业务单元等分类）
∙能够建立同一客户不同账号之间的相互参照
∙信托帐户和其他涉及受益人的帐户
∙锁定或停止特定的帐户
∙记录帐户特定的警告代码
∙识别休眠或长期不被使用的帐户
∙识别“客户经理”或“客户关系经理”
❑联机帐户查询包括：
∙帐户状态报告
∙交易清单
∙停付指令
∙完全的利息和费用的明细
∙自动的帐户关闭处理
❑帐单：
∙从生成类型可分为周期性生成、临时生成、当某个特定事件发生时生成，或在给定数量的交易完成以后生成
∙显示该客户的其他帐户余额
∙帐单的复制和拷贝
∙包括交易细节的文字描述
∙提供其他相关的信息给客户
❑计提利息和费用的详细通知，包括每个计提帐户利息和费用计算的完整的明细
❑自动或根据用户请求生成用户定义的，预定义格式的帐户报告，包括：
∙标准信函（比如利率更改）
∙非授权的或超额透支的建议
∙预先利息/收费通知，及应付日期/应付款通知
∙基金收取的确认
∙付款文件的交付
∙其它临时报告
❑支持单客户的帐户组（包括两个或多个帐户）的计息，收费，和报表功能：
∙灵活的基于帐户组头寸和活动的其它收费安排
∙生成帐户组的状态，计提和活动报告
❑记录客户帐户的户籍或法人单位
❑支持支票帐户管理流程，包括：
∙生成支票簿和存折的打印指令；
∙记录支票簿和存折的定购和发送；
∙跟踪和校验当前和以往发行过内容的系列号；
∙记录客户的停付指令和监视帐户行为以定位“停付嫌疑”
∙监督和报告帐户活动并突出异常行为
1.1.4产品管理
核心业务系统在产品管理方面应该至少包括以下几方面：
❑产品应该是：
∙具有唯一标识
∙由可变参数和产品组件来定义产品
∙无需程序员和操作员维护
∙指定产品的起始日、到期日
∙只给授权用户访问（除查询外）
∙能够支持大量的计息和收费规则，这些规则取决于客户类型、帐户组安排、行业/产业代码、担保关系等
❑当前产品清单包括：
∙现金（支票）帐户
∙活期性存款账户（有/无磁卡存取）
∙信托存款帐户
∙循环信用和信用额度
∙定期和可变的贷款（用绝对或基础利率）
∙定期和通知存款帐户
❑活期性存款账户（DDA）：
∙有利息或无利息
∙吸引合格的余额进行存款或贷款
∙根据合格的标准（例如余额，活动，或者营业额）吸引费用和佣金
∙可适用的透支限制
注：
现金支票帐户是一种DDA的产品，其主要的交易机制是使用有具有BACS标准的磁墨水字符识别或光学字符识别的编码条的一本支票簿。
❑定期存款产品包括固定期限定期存款，可变期限定期存款或在通知期后可赎回的定期存款
❑贷款产品：
∙固定期限，可变期限或在通知期后可赎回
∙附加贷款偿还的基础（即只付利息，本金加利息，只付本金，折扣，利息/附加费用）
∙贷款偿还进度的种类
∙对超额，拖欠和过期的处理标准
∙抵押品安全需求
∙年度进展报告的计算和报价单
❑产品应该支持灵活的费率输入，能够实时的将市场数据导入核心银行系统
❑支持分层定价，能够根据客户关系参数提出计价点、利率、付款条件、收费和费用减免、服务水平
❑成本清晰度，能够以每笔交易或其它作业为基础来确立变化的成本或风险
❑灵活的收费机制，能够根据业务规则来设置产品的收费
❑支持费用减免，能够设置参数以表明何时及多少费用应该免除。
费用减免条件应该包括余额、客户类型、促销方式等等
❑支持透支处理，能够收取帐户持有人的透支费和负利息。
系统必须能够首先处理最小的名目，以减少透支发生的次数
❑手工的收费更新，系统允许管理者、经理为某些客户或基于一些特定的帐户条件更新收费。
收费更新应该可以设置为自动过期
❑系统能够在产品粒度的层次上定义收费。
包括同一产品大类中的不同产品类型，以及不同的服务水平参数
1.1.5帐户交易管理
❑存款/取款（包括现金）
❑现金流动，分行间的现金管理（存款、取款等等），包括自动的审计追踪和总帐过帐
❑开户/关闭帐户，开户时必须提供姓名、地址、签名图像、对帐单的发送频率；
开户时可以自动地生成帐户号，也可以根据客户的喜好指定帐户号；
关闭帐户应该能够标识帐户为关闭状态，而不是从系统中删除该帐户
❑帐户维护，履行非金融性的维护任务或不产生日记帐条目的非银行的“静态的”交易
❑自动的清结算功能，根据合记式会计标准自动匹配全部的行内和行际的日记帐条目
❑余额管理，系统应该为任何接触点提供一致的、实时的余额，并且为系统间的内部调帐提供改进的异常报表/试算表
❑“锁定”选择，系统能够将任何帐户或子帐户关联为抵押帐户、指定帐户、欺诈检测和收款
❑正付款，系统必须提供正付款的功能，以支持代理机构与NCDST的通讯
❑系统应该能够处理交易分解，系统接收存款并将存款分解到不同的帐户，系统也可以处理单笔存款、多个记息日的交易
❑过帐，系统必须为每个条目提供过帐的功能
❑激活休眠的帐户，系统能够设置规则以激活休眠的帐户。
帐户只有通过手工处理并经过管理者的批准才能够被激活
❑管理者异常报告，由于明显的和有意义的原因造成的异常所产生的报告
❑收据的生成，在出纳工作站生成预打印的收据
❑在线的报表存储，系统提供在线审阅报表及按需打印报表的功能。
报表应该在线保留七年以供备查。
❑实时交易过帐到核心银行系统，所有的交易应该在线实时地被校验和过帐到核心银行系统
❑缺省的交易参数，系统为不同的交易类型提供缺省的交易字段和参数。
系统能够灵活地定义每种交易类型的缺省的头寸和信息
❑帐户休眠规则，系统能够设置帐户休眠规则（手工或自动）
❑交易定义的维护，系统能够创建、修改、删除、更新交易头文件并建立可共享的参数文件
❑帐户之间转帐
❑转帐到其它银行/由其它银行转入（通过接口）
❑直接借记指令（发布的/接收的）
❑撤消交易
❑用于自动转帐的扫描设备
❑银行支票/汇票的发行
❑贷款的提款和到期
❑贷款的偿还（预定的/非预定的）
❑定期存款的存入和到期
❑定期存款的提前支取（全部/部分）
❑外汇管理的业务
❑伴随性的事务（利息收取/利息支付，费用和佣金）
❑创建和维护交易类型，并将其作为参数放入交易处理的定义
❑当用户在线输入交易指令时，可以修正缺省的交易描述或在买卖契约表中增加附加的细节
❑在线交易的授权
❑记录停付的细节
❑管理者或交易者能对大批量的及高风险的交易的必要组件进行检查和编辑，并能够实现多级授权控制。
❑旅行支票的发行控制，监督控制和库存控制
1.1.6报表管理
本系统应该至少包括以下几方面的报表能力：
❑随机生成报表的能力，系统应该支持按非技术人员、多客户和多帐户的灵活的报表输出
❑客户对帐单，根据客户的要求提供客户对帐单，并能够以多种格式查看客户的存款和凭单交易
❑帐单，系统能够对透支帐户生成收费帐单
❑分行余额报表，能够以往来行分组查看当前的余额
❑MIS/EIS报表，系统能够定义、生成在线和归档的有效的管理报表。
管理报表至少包括资产和负债管理报表、贷款和信用管理报表、现金流预测报表
❑合并的明细表，系统应该支持合并的帐户明细表以反映公司的全部帐户情况；
设置交付期
❑对帐功能，系统能够自动生成含有高亮度显示的断点和故障点的试算表，具有使会计记帐流线化的潜力
❑预测报表，系统能够根据参数驱动的方法提供“WHAT－IF”类型的预测
❑定制报表，这些报表的范围和生成频率由需要报表的用户组确定，报表涉及的参数可能由其它相关的组设置
❑贷方分录报表，系统能够生成正确的贷方分录报表并遏制不影响客户余额的行际信贷
❑对人行和其他管制机构的报告
1.1.7出纳/分行交易管理
❑当分行与总行间的通讯连接中断时，能够继续处理交易，校验账号状态，停止付款。
脱机方式必须有明显的标示，并且能够支持在通讯恢复后的无缝联机
❑收款和收益，系统能够将收款和收益转到受益人的帐户
❑长期性的指令：
系统能够为其它银行和内部多币种交易处理长期性的指令交易
❑交易逆转：
系统能够处理交易逆转
❑系统能够在柜员交易屏幕支持自由格式的，多行的文本注释
❑监督者评审和编辑：
系统能够将巨额交易或高风险交易的必要细节发送给监督者或原始的交易方以供评审和可能的编辑，系统还应该能够实行多级认证控制。
交易的批准过程是通过工作流来实现
❑磁墨水字符识别或光学字符识别：
能够在分行系统支持基于分行的光学字符识别和磁墨水字符识别，以减少账号和其它标识的手工录入
❑交易描述：
系统能够让柜员或客户经理从交易清单中选择具体的描述，或使用自由格式的文本
❑签名规则：
系统能够为取款和取款限额规定签名级别。
级别应该是灵活的，分层的。
新帐户应该继承规则
❑建立收据记录：
建立、修改和删除收据
1.1.8管理和监控
❑限额的实现：
系统应该在限额/帐户/帐户组/子帐户的应用上具有灵活性
❑监控：
系统能够根据风险或其它参数监控指定的帐户
❑登陆和注销的安全机制：
用户ID的安全体系，联机和脱机的系统访问能力
❑帐户更新：
系统能够在帐户设立后修改帐户细节，受制于双重控制。
前台和后台均可对帐户进行更新
❑错误消息文件维护：
系统能够建立、修改和删除一条消息
❑帮助文本维护：
系统能够建立、修改和删除文本记录
1.1.9现金管理
❑监控/追踪：
客户/关系经理在现金余额、投资、绩效等方面的视图
❑执行交易：
由客户或关系经理激活
❑灵活的报表：
由客户或关系经理初始化的报表
❑安全/日志/审计追踪：
识别，归档和提取全部的交易记录和其它系统输入记录
❑系统能够将银行余额转入非银行的货币帐户（比如，过夜资金市场）
❑与业界会计标准的接口：
系统能够灵活地遵守不断变化的国内和国际的标准，并能够通过OFT或XML与客户端的应用连接
❑系统能够提供加速付款过程（收据、排序、存款、报表）的业务服务
❑网上银行：
系统能够提供以下的联机功能：
客户功能、客户档案维护、帐户余额查询、停付指令、支票发行文件维护、支票不合理收费的调整请求
❑客户支持：
客户能够联机访问系统从银行和CMCS系统查看帐户的预过帐情况
1.1.10总帐
❑自动过帐，比如从其它核心系统，Trema、Globus、BESS付款系统自动过帐
❑预算：
系统能够按交易、客户、帐户或任何它们之间的组合进行报告和分派盈利率
❑系统能够对任何作业的成本分摊到任何帐户或成本/利润中心
❑能够创建帐户间的父子关系，能提供多层帐户关系
❑分类帐应该整合在一起，任何对子帐目的改变能自动反映到父帐目
❑总帐系统必须提供父账目下不同子账目的自动对帐功能
❑系统应该能够在非更新模式下查看变更和条目（尤其在利息过帐时）
❑交易分类帐应该能保持开放一天以上而不影响随后的交易
❑系统能够根据需要进行交易的批处理和联机处理
❑系统能够处理回溯和远期的交易
❑系统能够分客户地显示资产和负债的进程，并支持每天的资产负债报表
❑系统能够自动生成所需的外部监管报告
❑系统提供灵活的会计图表和日记帐处理以遵照GAAT规定和所有权会计的规则
❑系统为风险分担者提供灵活的报表生成能力；
报表的修改应该由DBA来完成，而不是由编程人员来实现。
管理报表必须与BI应用相匹配
❑系统能够提供风险模型检测分析、产品开发分析、客户盈利率分析等等
❑系统能够取消/更正任何的交易详情，并自动重新计算利息计提、P/L分配和相应的日记帐逆转
❑系统能够对完成的交易进行实时的更正
❑系统必须能够支持对过去36个月的历史交易进行联机访问，并脱机保存48个月的历史交易
❑根据业务规则，系统能够对结算余额在总额或净利的基础上进行每日的利息计提
❑每日对帐应该提供试算平衡表、未定帐和对帐结束的能力
❑系统能够备份交易日志和总帐余额，并能够将总帐和交易历史恢复至任何时间点
❑系统能够根据可修改的业务规则自动生成支持交易的帐户
❑系统能够根据灵活的参数计算帐户余额
❑系统能够对送往总帐的批量交易使用可追踪的参照号
❑系统在总帐中能够支持分行的实体
❑系统能够将总帐信息导出至棋盘式表格应用，比如EXCEL等
❑系统能够显示日记帐的总额，打印、扫描日记帐
1.1.11安全管理
❑灵活的安全管理机制，授权用户可以方便地进行安全管理，并能够建立档案、具有审计能力。
授权用户能够在总部进行安全管理
❑能够将安全权限基于角色和子集分配给个人。
可以在总部或远程进行权限分配
❑能够生成详细的安全审核报告，指出何人、为何、何时和何地进行了安全设置，权限修改或删除
❑能够运用灵活的报表机制，轻松地生成用户档案报告
❑能够汇报和审核交易发生的特定地点
❑系统能够用工作流支持二级安全访问或修改的授权
❑系统能够基于时间参数强制注销。
时间参数应该根据工作角色和功能灵活地设置
❑系统应该支持LDAP安全基础架构。
包括用户工作站的单点登陆
❑系统应该保证分行按照用户登陆时的身份将操作员记录下来。
系统还应该处理原始操作员离开终端但未注销的情况
❑系统能够限制对一些特殊帐户或帐户群的访问。
特殊帐户包括VIP帐户和职工帐户
❑系统能够基于终端的物理位置限制对系统和系统功能的访问
❑在连续三次失败操作时锁定用户ID
❑系统能够自动生成违反安全的异常报告
❑系统支持用户口令的自动过期、最小的口令长度、强制口令使用数字和字母、禁止使用容易猜到的口令、禁止口令与用户ID一致、禁止设置口令为词典中的字
❑系统能够根据业界流行的加密方法对口令及客户敏感的数据进行加密
❑系统必须保证单用户单进程，比如一个用户在同一时间只能在一台终端登陆
❑对高风险的应用/交易，强制使用TOKEN和口令，比如安全管理和巨额基金转帐
❑系统能够基于预定的原则对不寻常的作业生成异常报告，以便监测异常的交易
❑对一些高风险的交易，要求用户输入附加的口令或重复的口令，以确保用户未离开交易中的终端
1.1.12特殊需求
❑系统每年能够处理超过23,000,000张纸质凭单，并能处理约10个帐户的交易占总交易量70－80%的情况
❑系统能够每天处理约10个帐户发生200,000笔交易的高峰流量。
对于单个帐户，系统能够每天处理50,000张纸质凭单
❑系统至少允许10个内部用户、200个外部用户同时使用，并支持两名核心银行系统管理员同步工作
❑根据法律的规定，系统支持多个主权帐户以便于外部政府机构对帐
❑通过备忘录文件或队列，系统必须能够适时对FRB和其它开户行的请求作出调整
❑通过备忘录文件，系统具有将信息从一个责任区域传到另一个责任区域的能力，以加速建立实体的过程
1.1.13接口
❑BAI下载－ZBA帐户：
对前一天的存款，能够处理从其往来行的ZBA帐户下载的BAI格式的文件
❑BAI下载－主帐户：
对交易和余额，能够处理从其往来行的主帐户下载的BAI格式的文件
❑CMCS接口：
系统能够从CMCS系统下载和上传数据。
数据必须通过接口与银行分类帐连接
❑FRBMICR数据接口：
从联邦储备局获得的数据必须能够与以Oracle为数据库引擎的异常处理系统相连接
❑ACH/EFT接口：
系统能够与被NCDST使用的ACH软件连接，以初始化金融机构间的电子转帐。
核心银行系统也可以提供自身的ACH功能
❑WITS/WIRS接口：
系统必须与NCDST的影像处理系统WITS/WIRS相连接，以便于将有效的支票记入DDA系统
❑WITS存款和DDA系统接口：
系统能够在每天交易结束时，将存款和调整记入DDA系统
❑停付数据接口：
系统必须能够从不同的机构，通过email、软盘和网上录入接收停付文件
❑正付款数据接口：
系统必须能够从不同的机构，通过FTP、从ITS和网上下载的文件接收支票发行文件
❑OSC预算代码对帐接口：
系统必须与CMCS系统连接，每月对收据和支出额进行对帐，并在核心业务系统和CMCS系统之间比较每月结束时的预算代码结余
❑与CMCS系统每月利息计提接口：
系统必须与CMCS系统连接，以保证每月将利息记入CMCS系统
❑ACH“减持”接口：
60个社区银行的每一家都在其银行分类帐中维持了最小的目标余额。
每天下午2:
00，系统与CMCS接口被调用，系统生成银行既有余额超出最小目标余额的“减持”量的报表。
该报表被手工键入到NCDST的ODFI的基于网络的ACH程序，并建立ACH格式的ACH借方文件，然后提交给ODFI。
NCDST想要自动化该过程
升级会员 