信贷管理系统需求总结，商业银行业务学习 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

做完了3个信贷系统了，很需要把这个系统的需求总结一下，希望以后能以consultant的姿态到客户那边跟他说信贷系统该如何如何的。
   很显然这个系统最基本的要求是能提供客户申请贷款，然后能把贷款发放给客户。但是贷款是客户向银行借钱，银行不会随随便便就把钱借出去，所以需要审批，审批需要详细的客户信息和审批流程。贷款发放后，银行必须采取一系列的监控措施来保证贷款的正常回收，以避免出现逾期、欠息等情况。决策层、信贷人员需要对贷款进行分析，所以需要贷款数据的查询、报表、多维分析、数据分析。贷款发放以后客户可能是分期还款，还有利息的计算等等问题一般不在信贷管理系统的范围，因为每个银行都有一个叫做核心系统的东西，核心系统其实就是一个会计系统，计算利息，余额是他们的工作。所以对于信贷管理系统来说又多了一个工作，就是与核心系统的交互，比如审批通过的贷款数据发往核心系统，贷款发放后贷款余额的变化必须接收过来等等。
所以整个系统大致可分为：客户管理、贷前业务受理、贷款审批、贷后管理、系统管理、贷款分析
一、客户管理
客户包括来贷款的客户，与银行贷款合作的企业，比如房贷中的楼盘开发商，还可能包括合作银行，联行等。具体看业务范围决定，最主要的当然是贷款客户。
为了避免贷款风险，贷款客户信息越多越利于考察是否能发放这笔贷款。所以客户信息应该设计的很详尽，包括客户基本信息(姓名、工作)，客户信用信息（公用事业拖欠等，似乎有些不可能实现），客户以往贷款记录(本行的记录容易实现，他行的难办)，客户关系人信息（夫妻父母等），客户信用评分（根据评分标准打个信用分，是否科学不清楚，这个最理想的实现是通过数据挖掘，未来可能是个市场），企业客户还需要提供财务信息，还有客户黑名单管理。
客户信息涉及到以往信息的查询，在办理业务的时候一般以身份证号（军官证号等）作为唯一检索条件，所以最好把唯一检索客户的条件设计成证件种类＋证件号码，身份证号重复咋办？加一位标识重复的这些怪人。
另外一个尴尬的地方是，因为客户来申请贷款一般都会要求在本行开户，也就是说在核心系统肯定有该客户的信息，所以是否在信贷系统重新录入客户信息是一个值得考虑的问题，但是核心系统的客户信息一般比较简单，无法满足信贷的要求，一般只能获得基本信息，其他信息还是需要维护的。
二、贷前业务受理
受理就是信贷业务员准备给一个客户贷款了，需要他填写一份贷款申请资料，当然通过信贷系统输入这些信息最方便。
这个模块最麻烦的地方在于不同的贷款需要录入不同的信息，而且对于一个银行来说不同的贷款有非常多，房贷、车贷、公司贷款等等。对于不同的贷款银行称之为产品，并且随着市场的变化贷款产品也是变化的，所以一般来说需要贷款产品的动态配置，这个任务可以放在系统管理模块。所以贷前业务受理就是如何根据不同的贷款产品录入相应的信息的问题。
三、贷款审批
对于开发人员来说这是一个工作流，对于银行审批人来说这个最好是一个工作台，每天上班打开系统的我的工作台就能看到今天要审批的贷款，填上自己的意见，调整可以调整的参数（比如贷款金额，期限等）就通过。
这个模块设计的好能比传统纸质文件审批过程大大地提高生产效率，特别是有些偏僻地支行必须把他们的贷款一级级的向上审批送往总行，这是多么艰巨的一个过程。通过联网的审批系统就能轻易解决了。
比较麻烦的是不同级别的权限、额度控制问题。不同级别的人应该拥有不同的最高额度审批权限。
四、贷后管理
包括贷款的五级分类管理及风险预警，贷款变更管理（展期，抵押、担保变更，提前还款等）
五、系统管理
系统中需要用到的基础数据的管理。包括信贷员管理，贷款产品管理，利率管理，其他一些可以配置的参数管理等。
六、贷款分析
上面五个模块都是业务系统，也就是oltp系统，这个模块不是oltp,而是olap.所以设计原则应该是不同的，很多银行也把他独立开来开发，然后通过potal集成到信贷业务系统中。
需求主要包括：报表、查询，多为分析，数据挖掘。绝大部分需求集中在报表、查询，后两者有些银行甚至不知道他们的存在，更别说提出需求了，尽管在现在的项目需求上写了：“①自动组合功能：由于部分信贷报表内容较多，表头大，为能适应管理需要，报表表头能根据需要进行组合，请开发公司提供。②汇总功能：A、省联社级：汇总各地（市）数据。B、省联社地（市）办事处级：汇总各市、县联社（合总行）的数据。C、县联社（合总行）级：汇总本县下属各信用社（支行）的数据。D、信用社（支行）级：本机构所辖各网点数据。③统计图功能：报表中的数据，可按具体要求自动生成所需要的统计图形（如：趋势图、折线图、直方图、饼形图等）。”这些实际是标准的多维分析需求，但是很不幸的是他们没有配合去买个olap的工具，而是要我们通过报表来实现，damn it!
（一）查询需求：(也可以在业务系统中实现，在哪边实现需要权衡考虑)
客户查询（名称,额度级别，贷款余额，信用余额，表内余额....），合同查询（合同号，风险分类，合同余额...),借据查询,流水查询(贷款发生的流水）
（二）报表需求
1、对外报送报表
贷款质量迁徙情况表、贷款按逾期时间分类情况表、贷款质量五级分类月报表..
2、客户清单类报表
最大N家贷款户清单、 最大N家不良贷款客户清单、最大N家逾期贷款清单等..
3、合同清单类报表
贷款清单查询、股东业务清单、贷款风险分类迁徙清单...
4、不良贷款报表
不良贷款收回方式月报表（风险分类、期限两种）、不良贷款变动情况月报表（风险分类、期限两种）、本期收回不良贷款流水清单、本期新增不良、本期......
5、总行用报表
信贷资产五级分类机构汇总表、总行审查审批项目清单、总行信用项目审批/否决通过项目情况表、授信审批部×年×月份工作量统计表（后面几个报表侧重审批控制的银行需要）
6、考核报表（主要是考察信贷员工作情况）
信贷员业绩查询、柜员业务量统计
（三）多维分析需求
1、合同多维分析
贷款合同是贷款管理的主线，所以这个角度来分析是必不可少的。
维度主要有：日期、机构、客户类型、业务品种、发生类型、币种、期限月、实际发放年月、实际到期年月、终结年月、逾期天数、欠息天数、风险分类、国标行业投向、本行投向、主要担保方式、国标行业分类、民营标志、经营组织形式、企业规模、所在行政区域、信用等级
度量值主要有：合同金额、合同余额、未用余额、逾期余额、欠息余额、表内欠息余额、表外欠息余额、本期发放金额、本期收回金额、合同笔数
2、借据多维分析
借据是放款凭证之一，从这个角度来分析贷款也是很必要的。
维度：日期、机构、核心机构、客户类型、业务品种、发生类型、币种、风险分类、借据类型、发放年月、到期年月、终结年月、期限月、会计科目、原会计科目、逾期天数、欠息天数
度量：借据金额、借据余额、表内欠息余额、表外欠息余额、本期发放金额、本期收回金额、借据笔数
3、审查审批多维分析
从这个角度进行审批情况分析，包括机构、信贷员考核
维度：信贷员、日期、机构、贷款币种、贷款风险分类、贷款审批日期、贷款审批通过/否决、....
度量：贷款比数、贷款金额、贷款余额、审批通过笔数、否决比数....
(四）数据挖掘需求
待探索的空白区域....
作者：eyejava 来自：上海
文章出处：j·a·v·a·e·y·e   冒死发一个（希望版主表删偶这个贴贴） http://www.(呵呵被ITPUB屏蔽了).com/topic/38720?page=1

[ 本帖最后由 kamkam 于 2009-6-3 15:29 编辑 ]
不错。工作就是要这样。把眼前的事情做好，想着未来。
总结，完善。楼主总有出人头地的一天的。
谢谢搂主分享
一中，客户信用信息（公用事业拖欠等，似乎有些不可能实现），客户以往贷款记录(本行的记录容易实现，他行的难办) 你们系统中有没有人行征信系统接口？信用信息的搜集是信贷部门的事情，是业务上的事情。客户信用评分应该是一个模型。
所以是否在信贷系统重新录入客户信息是一个值得考虑的问题，但是核心系统的客户信息一般比较简单，无法满足信贷的要求，一般只能获得基本信息，其他信息还是需要维护的。~~~~~~~~~应该重新录入，如泥自己所说，信息量是个问题。此外，我引申出另外一个问题：你们的信贷管理系统如何与核心业务系统间进行交互？
二，四太略了，恰恰是银行客户比较关注的；这两块是大头。如果这时一个需求学习的话，是远远不够的...
六、贷款分析
上面五个模块都是业务系统，也就是oltp系统，这个模块不是oltp,而是olap.所以设计原则应该是不同的，很多银行也把他独立开来开发，然后通过potal集成到信贷业务系统中。
~~~~~~~~~~~~~~这部分我不是很理解，貌似还是一个交互的问题？
感谢楼上2位的关注，这个帖子是我从其它社区中看到的（貌似我直接输入原社区名称会被论坛自动翻译成“垃圾社区”，汗一个），直接挑水，原作者是个java程序员，从事信贷系统的开发，我看了这篇文章后觉得获益良多。
对于 头狼阿布 提出的疑问，我也不太清楚。如果有兴趣，可以到原帖的社区联系一下原作者也不错噢。（PS：不是帮他家卖广告）
[ 本帖最后由 kamkam 于 2009-6-3 15:25 编辑 ]
原帖由 littlepigabu 于 2009-6-3 12:01 发表

谢谢搂主分享
一中，客户信用信息（公用事业拖欠等，似乎有些不可能实现），客户以往贷款记录(本行的记录容易实现，他行的难办) 你们系统中有没有人行征信系统接口？信用信息的搜集是信贷部门的事情，是业务上的事情。客户信用评分应该是一个模型。
所以是否在信贷系统重新录入客户信息是一个值得考虑的问题，但是核心系统的客户信息一般比较简单，无法满足信贷的要求，一般只能获得基本信息，其他信息还是需要维护的。~~~~~~~~~应该重新录入，如泥自己所说，信息量是个问题。此外，我引申出另外一个问题：你们的信贷管理系统如何与核心业务系统间进行交互？
二，四太略了，恰恰是银行客户比较关注的；这两块是大头。如果这时一个需求学习的话，是远远不够的...
六、贷款分析
上面五个模块都是业务系统，也就是oltp系统，这个模块不是oltp,而是olap.所以设计原则应该是不同的，很多银行也把他独立开来开发，然后通过potal集成到信贷业务系统中。
~~~~~~~~~~~~~~这部分我不是很理解，貌似还是一个交互的问题？
我来以我的经验来解答一下：
一、通过抽取工具每天凌晨将要交互的表的数据从核心抽取到信贷系统数据库中。也有用联邦数据库来实现这一目的。至于核心应该不会需要信贷的数据。当然现在大部分信贷系统都有实时接口，在需要相关数据的时候触发实时报文从核心取数据。
六、业务系统为OLTP，主要是实时性，数据较为频繁的插入删除修改。所以相应的表结构设计要满足该要求。而统计分析系统为OLAP，数据不会频繁的变动，主要为了满足查询的要求。你可以从网上搜索一下OLTP和OLAP的区别，非常详细。    因为在业务系统数据库表设计的基础上统计分析查询不方便且占用资源（比如你想出张报表你在oltp中可能要连10张表才行，效率如何显而易见），会导致业务系统反应慢，影响业务办理。所以要单独建一个数据库来做统计分析，与业务库分离。发展完善了统计分析系统就是一个整合各个业务系统的数据仓库，ETL、整合、OLAP工具、多维分析、数据挖掘等概念就是后续工作了。
数据仓库建立好了，可以方便的出报表供内部监测和外部监管的需要。lz也说到多维分析。储备多年的数据之后远景目标就是数据挖掘，让银行的宝贵数据真正体现作用。那得需要真正懂业务又懂技术的人来做的。
希望对你有所帮助。

总结得不错，呵呵。。。不过由此来看，似乎应该把客户信息统一起来，作为整个银行系统的一个支撑，而不是每个系统各搞一套，各存一部分数据。