银行信息系统的流程架构Word格式.docx

银行信息系统的流程架构Word格式.docx

《银行信息系统的流程架构Word格式.docx》由会员分享，可在线阅读，更多相关《银行信息系统的流程架构Word格式.docx（10页珍藏版）》请在冰豆网上搜索。

这时，一些早期设计的银行计算机信息系统，面对各种各样新、旧业务，仅按手工操作的方式随意设计的流程，使系统处理流程显得复杂和凌乱：

不同时期上线的系统、不同的研发团队、不同的产品，尽管其业务流程相似，但计算机的处理流程可能会完全不一样。

这种流程的不规范给系统维护与新产品的研发增加了非常大的困难。

研究信息系统的流程架构，就是对银行在各类客户服务里的处理流程进行分解、抽象、综合并归纳。

理顺内部系统之间、内外系统之间的流程关系，并且把系统内外的处理流程有机地结合起来。

根据银行在不同流程中充当不同的角色，构建一个合理的流程规范。

从而结合流程架构去设计信息系统的架构。

银行信息系统里最基础的系统是银行的交易处理系统。

如上所述，银行交易处理系统要处理的业务，有辖内与辖外，有本行与跨行、有本地或异地之分。

下面，对交易系统的流程进行宏观分析：

（一）银行电子化前

在银行电子化前，银行面对仅涉及本营业点的业务时，业务处理流程相对简单。

通常是在营业点柜台由柜员受理客户的服务要求（收单），然后直接由该柜员处理。

对于核算业务，通常就是一借一贷，在本营业点就可以完成。

然后把结果返还给客户。

当业务需要跨营业点（跨行）处理时，流程就相对复杂了。

第一步，收单行收单后，先在登记簿作登记，并作相应预处理（例如借方账户处理）。

然后，如果涉及的对方行与收单行在同一个城市，则由收单行提出同城交换；

如果涉及对方行是异地的，则提出联行交换。

第二步，等对方银行做了相应处理（例如贷方账户处理）并交换提回后，再作完整的处理。

通常，同城交换提回最快要隔一个交换场次，联行交换提回最快要隔天。

第三步，把结果返还客户。

（二）银行电子化后

银行电子化后，各银行信息系统跨行业务流程有了很大的变化。

一是与不同的银行业务联网的进度、范围和支持方式相关，二是涉及异行业务还与人民银行的电子化进度和支持方式相关。

银行信息系统面对不同地域和不同时期跨行业务的流程有很大的区别。

二、规划流程架构

随着银行电子化进程的深入，人民银行和主要的银行都已支持联网实时地处理跨行业务，且业务的做法也相对规范和统一。

为了简化与规范交易系统的处理流程，按不同的服务角色、设计一个统一的交易处理流程条件已经成熟。

从银行交易流程的宏观分析可见，对银行大多数业务特别是传统业务来看，无论是原来的本网点业务，还是跨网点、跨地域、跨行的业务，宏观流程主要都是收单、借方账户处理、贷方账户处理、处理结果返回四大部分。

其中根据收单行与开户行是否相同，又可以再细分为：

仅涉及本营业点业务（简称本行业务—下同）和跨营业点业务（简称跨行业务—下同）两种。

不管是本行业务和跨行业务，根据银行业务的宏观流程，银行的角色有三个，对应三方面的处理：

∙收单行（代理行）：

收单、相应处理、结果返还客户；

∙借方开户行：

借方账户处理和相关处理；

∙贷方开户行：

贷方账户处理和相应处理。

当然，这三个角色，在某些交易场景，对于某个银行，会有重合。

例如，对于纯本营业点业务，上述几个角色完全重复；

而涉及跨行的业务，则几个角色会有不同的组合。

下表穷举三种角色的各种组合情况：

图：

银行角色的组合

从上表可见，银行三个角色组合的场景中，场景1相当于完全的本行业务，场景2—7是涉及跨行的业务，场景8其实与本行无关。

如果我们交易系统的处理流程基本是根据银行的上述三种角色的不同职能分别进行系统设计，那么，各种业务场景就可以通过这些处理模块的组合完成。

也就是说，所有的银行交易业务，均可以通过收单（结果返回）、借、贷三个动作的组合所包含。

一些较复杂的业务，也只是一借多贷、或者是一贷多借而已，也没有突破这三种动作之外。

这样，我们就可以通过流程定制，通过三种角色的不同组合，快速生产出各种银行新业务。

需要注意的是，本章所指的本行与他行，针对不同的概念对象有不同的内涵。

∙在信息系统架构概念上

本行与他行指的是借方与贷方是否在同一个独立运行的信息系统实体内。

对于大多数银行而言，整个信息系统的交易系统是一个不可分割的独立运行实体。

那么，借方与贷方只要都是本银行的客户，不管是否在同一个核算网点，均算是本行业务。

但从当前信息系统架构发展的方向看，大型的银行信息系统应该将其交易系统按服务划分为更多的独立运行实体。

如：

对私系统、对公系统、卡系统等。

如果真的实现在一个信息系统内有不同的独立运行的服务系统。

那么，在一个银行的信息系统内，只要借方与贷方跨服务系统，则算是跨行业务。

∙在账务处理概念上

本行与他行指的是借方与贷方是否在同一个基础核算网点（核算单位）内。

如果业务全在同一个核算网点内，称之为本行业务。

如果业务跨一个核算网点，称之为跨行业务。

从账务上，对于跨行业务，银行的三个角色都不需要特别考虑该跨行是同一个银行内还是异行，是同城还是异地。

一方面，如果参与一个完整的客户服务流程里的三个角色的银行，都已经实现了计算机联机业务处理，那么，地域方面的差异已经可以不在应用系统设计的特别考虑范围内，所以也就无所谓是同城还是异地。

另一方面，不管是本行还是他行，对于核算单位本身而言，其会计分录完全是一样的。

最终的区别仅在于清算的层级、范围等具体细节上。

而清算往往与交易本身是分离的。

结论是，对于一个设计合理的流程架构，收单行的处理，不需要理会借方行、贷方行是谁，是本行还是他行，是同城还是异地。

其处理的内容和流程完全一样，仅需要关注作为收单行的相应处理就行。

同样，借方行和贷方行的处理，也不需要理会是谁收单，是本行还是他行，是同城还是异地。

其处理的内容和流程也是完全一样，仅需要关注作为对应账户的开户行所要作的相应处理就行。

这样一来，所有的处理（本行、他行，本地、异地）就变得简单和规范。

从上述分析可以得出另外一个结论。

在电子化实现后，可以有一些金融机构，仅有渠道，完全没有客户，所有业务均是代理业务——收单。

目前在国外，一些专门提供ATM或POS服务的公司就是专门从事收单的机构。

也可以有一些金融机构，可以完全没有渠道，仅作为开户行（发卡行），所有收单均由其它代理行代理。

一些国际发卡公司就是只发卡，不经营渠道的机构。

所以，理论上，也可以存在专做渠道的银行或完全没有渠道的银行。

下面，以结算业务为例，举例说明各种交易场合的处理流程。

图中蓝色框表示是一个独立运行的计算机应用环境（在当前，通常是相当于某银行的交易系统），包括软硬件设备及其处理。

其中可以分为几大部分：

本行渠道前置、他行渠道前置（用于与他行或其它合作方连接）、渠道整合、服务交付、收单行、借方行、贷方行。

黄色框表示独立运行系统以外的计算机应用环境（在当前，通常是他行或其它合作方），也包含了软硬件设备及其处理。

其中只列出与本行直接相关部分：

收单行、借方行、贷方行。

至于他行的内部结构及他行的渠道，由于与本行没有直接连接关系，所以没有列出。

（一）场景一：

收单-本行，借方-本行，贷方-本行

场景1

（二）场景二：

收单-本行，借方-本行，贷方-他行

场景2

（三）场景三：

收单-本行，借方-他行，贷方-本行

场景3

（四）场景四：

收单-本行，借方-他行，贷方-他行

场景4

（五）场景五：

收单-他行，借方-本行，贷方-本行

场景5

（六）场景六：

收单-他行，借方-本行，贷方-他行

场景6

（七）场景七：

收单-他行，借方-他行，贷方-本行

场景7

上述7个场景只是宏观地描述在一个客户服务里，银行的三个角色间的流程架构。

实际上，在每一个角色的处理中，还有不少的流程处理细节需要在各种角色内通过内部流程去实现。

从上面七个场景的处理流程可以看出。

从交易系统流程架构的视图看，图中每一个方框可以表示为一个流程节点。

从应用系统应用架构的视图看，图中每一个方框可以表示为应用构件或服务。

无论哪一种场景，图中每一个流程节点（服务）只与固定的其它一些流程节点（服务）连接，接受相同的服务请求，进行相同的内部处理，返回相同的处理结果。

所以，完全可以标准化。

其中，服务交付是一个关键的流程（服务）。

它起到服务的解释和分解、服务交付的路由选择、过程服务结果的转发、最终服务结果的打包等功能。

完成这个服务的构件，就是我们通常说的企业级服务总线。