银行系统接口设计（银行系统架构设计）

本篇文章给大家谈谈银行系统接口设计，以及银行系统架构设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享银行系统接口设计的知识，其中也会对银行系统架构设计进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何更好地设计REST API
• 2、手机银行转账需要用到多少个接口
• 3、银行数据仓库体系实践（7）--数据模型设计及流程
• 4、银行系统如何选择专业存折打印机
• 5、银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持，需具体

如何更好地设计REST API

由于REST可以降低开发银行系统接口设计的复杂度，提高系统的可伸缩性，增强系统的可扩展性，简化应用系统之间的集成，因而得到了广大开发人员的喜爱，同时得到了业界广泛的支持。比如IBM，Google等公司的很多产品都提供了REST API给开发人员；与此同时，大量的开源项目和云计算服务都提供了REST API接口。
而在最近，一些新产品的开发甚至已经几乎完全抛弃了传统的类似JSP的技术， 转而大量使用REST风格的构架设计， 即在服务器端所有商业逻辑都以REST API的方式暴露给客户端， 所有浏览器用户界面使用widget、Ajax、HTML5 等技术，用HTTP的方式与后台直接交互。
那么， 在REST API爆炸式增长的今天， 我们应该如何更好的设计我们的接口， 来提高我们的API的可用性，易用性，可维护性与可扩展性呢？本文将从以下方面与您探讨REST API设计方面的最佳实践：
如何规划资源标识结构与URI模式
如何根据应用场景提供内容协商
如何正确的使用HTTP响应代码
如何处理缓存和并发请求
如何利用数据冗余和链接元素
先决条件
如果您具有如下知识与经验，将有助于您阅读和理解本文章的内容 。
REST相关的基本知识；
HTTP协议的基本知识；
一定的Web开发经验。
REST简介
REST是英文Representational State Transfer的缩写，是近年来迅速兴起的，一种基于HTTP、URI以及XML这些现有协议与标准的，针对网络应用的设计和开发方式。它可以降低开发的复杂度，提高系统的可伸缩性。
REST的核心是可编辑的资源及其集合，用符合Atom文档标准的Feed和Entry表示。每个资源或者集合有一个惟一的URI。系统以资源为中心，构建并提供一系列的Web服务。REST的基本概念和原则包括：系统上的所有事物都被抽象为资源；每个资源对应唯一的资源标识；对资源的操作不会改变资源标识本身；所有的操作都是无状态的；等等。
在REST中，开发人员显式地使用HTTP方法，对系统资源进行创建、读取、更新和删除的操作：
使用POST方法在服务器上创建资源
使用GET方法从服务器检索某个资源或者资源集合
使用PUT方法对服务器的现有资源进行更新
使用DELETE方法删除服务器的某个资源
图 1. 用 HTTP 方法操作相册系统资源的简单范例
更好的规划你的资源标识结构与URI模式
REST 中，最基本的莫过于资源标识结构和URI模式了。更好的规划银行系统接口设计他们，是我们的API设计取得成功的最关键的一步。
首先，我们来看看基本资源类型
上文中提到，在REST构架的设计中，系统中的所有事物都被抽象为资源。
在一个文档系统中，文档、目录、注释、草稿等等，是组成系统的资源。
在一个银行系统中，客户信息、理财产品、利率信息、网点信息等等，是组成系统的资源。
在一个航空客票系统中，旅客信息、机票订单、航班信息、机场信息等等，是组成系统的资源。
这些资源，通常在系统中以“Entry”的形式出现。下面的代码样例向您展示了一个常见的“Entry”资源。
清单 1. 一个简单的Entry资源样例

以下是引用片段：
REST API 请求：
GET http://example.com/航班信息/CA827/entry
<entry
<id CA827 </id
<link href="航班信息 /CA827/entry" rel="self"/
<title type="text"CA827 </title
<published2010-08-24T02:35:40.937Z </published
<updated2010-08-24T02:35:40.937Z </updated
<ca:fromBeijing </ca:from
<ca:toChangsha </ca:to
<ca:time09:30:00 </ca:time
<ca:aircraftAB330 </ca:aircraft
<summary type="text"/
</entry
我们会注意到，这些资源，在描述了某种事物的同时，还有可能存在一定的层次结构关系。比如，文档从属于某个目录，注释从属于文档；旅客信息可以从属于机票订单，也可以从属于某个航班。
当我们的资源有这种层次关系的时候，我们不妨在URI模式的设计中，用复合的URI来帮助开发者更好的理解和设计资源。
比如， 针对一个文档的评论， 他的URI模式可以设计成如下：/文件夹/[文件夹名]/文件/[文件名]/评论/[ 评论唯一标示 ]。 这样，在构造和解析URI的过程中， 可以帮助开发者更好的理解系统，设计程序。
其次，我们来看看集合资源类型
资源，除了作为独立个体可以被访问，还可以由多个个体组合成一个集合，在系统中，通常以“feed”的形式存在。资源的集合， 可以是处于相同层次上，有相同从属关系的一组资源，比如一个文件夹下的所有文件； 也可以是根据某种条件查询出来的查询结果的资源集合，比如所有30岁以上40岁以下，拥有100万资产以上客户的名单。
下面，我们来讨论一下设计集合类型资源的REST API时需要考虑的问题。
使用过滤条件来帮助用户更准确地获取数据
我们要返回的资源集合，无论是否有相同从属关系，大部分时候都需要进行必要的过滤，提供足够的过滤参数，查询参数， 能够帮助开发者高效的，准确地获取所需要的数据。 在服务器端过滤数据通常比客户端高效，并且减少了不必要的数据传输，可以大大减少网络开销，提高执行效率。
最常见的过滤条件，是通过URL参数实现，比如/环境工程系/学生? 籍贯=北京性别=女。
很多时候，我们需要制定更加复杂的过滤条件，那么我们可以有两种选择：
首先，我们可以使用正则表达式或者服务器可以理解的语法，比如/环境工程系/学生?filter=age between (15, 18)
其次，我们还可以使用POST方法，携带一个文件来描述复杂的查询条件，文件的格式与语法通常需要在服务器端有相应的设计与定义。不过通常POST方法没有缓存机制，因此不是查询数据的首选。
使用排序来帮助客户端更好的展现数据
虽然进行客户端排序对于开发者来说是件轻而易举的事情，但是直接得到已经排序的返回结果，仍然是大部分开发者所期望的。尤其是很多时候，我们在浏览器，使用 Widget 展示结果，不适宜在客户端存储大量数据进行内存排序。
排序， 通常有2个参数，一个是用来排序的字段，一个是排序的升序降续方式。比如我们可以用支持这样的参数组合的手段，提供基本的排序能力：?sortOrder=ascsortField=age
使用分页来帮助客户端处理大量数据
由于返回的结果可能有几百几千条记录，将这些记录一次性的返回给客户端是不现实的，巨大的网络流量开销和客户端数据区的内存开销，都是我们在应用开发的时候不希望看到的，因此，如果你的集合资源有可能有大量的数据返回，请务必提供分页的功能支持。
我们通常用一个以上参数来制定一个返回结果的区域，比较常见的有下面两种：
一种常见于用固定行数的表格来展示数据，用当前处于第几页和每页返回多少行数据来确定需要的数据， 比如/所有学生?page=5pagesize=50
另外一种常见于用更加灵活的界面展示数据，用从第几行开始，一共返回多少行数据来确定需要的数据， 比如/所有学生?startIndex=27count=22
下面是一个来自IBM developerWorks的API样例，尝试请求该API，你可以看到该集合很好的支持了结果的分页与排序。同时我们从返回的信息中可以看到，每个文档Entry的URI都按照/社区库/[社区库ID]/文档/[文档ID]的复合URI的模式设计的。
清单 2. IBM developerWorks的某个社区文件库的集合资源的API

以下是引用片段：
REST API 请求：
GET https://www.ibm.com/developerworks/mydeveloperworks
/files/form/anonymous/api/communitylibrary
/0a7c97bb-6cf9-4ddb-a918-80994e7b444d/feed?
pageSize=5page=1sK=modifiedsO=dsc
最后，我们来讨论一些特殊资源类型
理想的REST世界，一切事物都抽象为资源，一切操作都抽象为增删改查。然而，所有事物与操作都可以很容易的按照这个规则作抽象吗？让我们看看这个例子：
检入和检出一个文档----这个时候，我们要处理的资源是一个文档，然而增删改查似乎都无法与“检入检出”这个动作进行对应。当然，我们可以在文档资源中，设计一个检入检出状态的元素，通过编辑文档资源来实现。但是，这种设计从自然语义上看，并不是很贴切；并且增加了资源编辑操作的复杂度。
如果我们来定义一个新的集合----“我检出的文档”，用创建一个集合资源来对应检出（创建一个文档锁），用删除一个集合资源来对应检入（删除一个文档锁）， 是不是逻辑上可以变得更加清楚？
在REST这个以名词为核心的构架结构中，当你遇到一些动词特性比较强的操作，而又很难用原始资源的增删改查来匹配的时候，不妨换个思路， 通过引入新的逻辑资源集合的方式， 来进行API的设计与规划。
理解和使用内容协商
我们的开发者在发送一个REST API请求的同时，根据应用场景，针对相同的资源，可能会期待不同的返回形式。
比如，我希望根据用户客户端语言，同一个资源的内容可以返回不同的语言。又比如，当我使用Java编程的时候，我希望得到ATOM格式的返回结果，而当我使用JavaScript编程的时候，我希望得到Json格式的返回结果。
因此，我们在设计REST API的时候，应该提供完备的内容协商能力。
使用URL参数进行内容协商
最容易想到的自然是通过URL参数进行控制，我们经常看到形如/航班号/entry? format=JSON这样的URL。这种方式的优势就是简单灵活， 你可以通过任何 URL 参数来组合你的输出格式。
下面是一个来自IBM developerWorks的API样例，尝试请求该API，你可以看到该集合是如何支持不同的输出格式请求的。
清单 3. IBM developerWorks的文件服务标签云的API

以下是引用片段：
REST API请求，要求返回XML格式数据：
GET https://www.ibm.com/developerworks/mydeveloperworks
/files/form/anonymous/api/tags/feed?format=xml
scope=documentpageSize=30sK=cloudsO=dsc
REST API请求，要求返回JSON格式数据：
GET https://www.ibm.com/developerworks/mydeveloperworks
/files/form/anonymous/api/tags/feed?format=json
scope=documentpageSize=30sK=cloudsO=dsc
使用Accept头进行内容协商
使用URL参数，简单灵活，但是也由此带来了设计上的随意和不标准。并且，过多的参数会导致URL的可读性变差，更有甚者，可能会导致URL过长，超出规范，API请求无法执行。
更为标准的内容协商方式是使用HTTP头。我们通常使用Accept来设置我们接受的返回结果的内容格式，用Accept-Charset来设置字符集，用Accept-Encoding来设置数据传输格式，用Accept-Language来设置语言。
使用URI模式进行内容协商
还有一种模式，就是将协商设置直接作为URI的一部分，将不同的返回视为不同的资源，比如/航班号/json来返回JSON格式的结果，用/航班号/atom来返回ATOM格式的结果。
正确的使用HTTP响应代码
作为API的设计者，正确的将API执行结果和失败原因用清晰简洁的方式传达给客户程序是十分关键的一步。 我们确实可以在HTTP的相应内容中描述是否成功，如果出错是因为什么， 然而， 这就意味着用户需要进行内容解析，才知道执行结果和错误原因。因此，HTTP响应代码可以保证客户端在第一时间用最高效的方式获知API运行结果，并采取相应动作。
转载，仅供参考，祝你愉快，满意请采纳。

手机银行转账需要用到多少个接口

从支付系统到银行系统，五个接口就能全方位对接
首先，银行系统和普通互联网公司系统有差异，银行或大型金融公司对安全性要求很高，对接前商户要确认对接形式，是互联网还是专线，因为这两者银行系统接口设计的对应技术存在差异。银行安全标准对于商户侧的开发部署环境，软件版本的要求是什么样的也要提前银行系统接口设计了解。
比如银行可能会有 PCI DSS 的要求，要求商户端服务端的 SSL 和 TLS 协议有版本要求。以及银行的测试，生产环境的接口联通，是否需要提前做防火墙开墙，IP 地址是否开启白名单配置以供访问，这些问题不提前弄清的话，会产生网络通讯的问题。
银行处理交易大部分是同步接收请求，异步进行处理。所有交易资金都有处理时效。商户设计需要考虑，和银行确认交易和资金处理的时效。在上线前有很多测试需要做，因为内部ID管理非常严格，会提供一套指定的测试案例，要求商户按照指定测试案例完成对接测试，有些银行要求作为接入的对接商户，测试范围必须大于要求的测试范围。

银行数据仓库体系实践（7）--数据模型设计及流程

数据仓库作为全行或全公司银行系统接口设计的数据中心和总线银行系统接口设计，汇集银行系统接口设计了全行各系统以及外部数据银行系统接口设计，通过良好的系统架构可以保证系统稳定性和处理高效性，那如何保障系统数据的完备性、规范性和统一性呢银行系统接口设计？这里就需要有良好的数据分区和数据模型，那数据分区在第三部分数据架构中已经介绍，本节将介绍如何进行数据模型的设计。

1、各数据分区的模型设计思路：

       数据架构部分中提到了在数据仓库中主要分为以下区域，那各数据区域的主要设计原则如下：

       （1）主数据区：主数据区是全行最全的基础数据区，保留历史并作为整个数据仓库的数据主存储区，后续的数据都可以从主数据区数据加工获得，因此主数据区的数据天然就要保留所有历史数据轨迹。

        1) 近源模型区：主要是将所有入数据仓库的数据表按历史拉链表或事件表（APPEND算法）的方式保留所有历史数据，因此模型设计较简单，只需要基于源系统表结构，对字段进行数据标准化后，增加保留历史数据算法所需要的日期字段即可。

        2)整合模型区：该模型区域按主题方式对数据进行建模，需要对源系统表字段按主题分类划分到不同的主题区域中，并主要按3范式的方式设计表结构，通过主题模型的设计并汇总各系统数据，可以从全行及集团角度进行客户、产品、协议（账户、合同）分析，获得统一视图。比如说，全行有多少客户、有多少产品？通过主题模型事先良好的设计和梳理，可以很快获得相关统计数据。

       主数据区的模型设计按顶层设计（自上而下）为主，兼顾应用需求（自下而上）的方式，即需要有全局视角，也要满足应用需求。那顶层设计主要是需要从全行数据角度对源系统的主要业务数据进行入仓，获得全行客户、业务数据的整体视角，同时又保存所有交易明细数据，满足后续的数据分析需求；应用需求指源系统数据的入仓也需要考虑当前集市、数据应用系统的数据需求，因为数据需求是千变万化的，但是只要保留全面的基础的业务数据，就有了加工的基础，当前的数据需求只是考虑的一部分，更多的需要根据业务经验以及主题模型进行数据入仓和模型设计。

        主数据模型的设计主要自上而下，近源模型层虽然比较简单，但设计步骤和整合模型类型，分为以下几个步骤：

       步骤1：系统信息调研，筛选入仓的系统并深入了解业务数据；

       步骤2：对入仓系统进行表级筛选和字段筛选，并将字段进行初步映射；

        步骤3：根据入仓字段按一定规范设计逻辑模型；

       步骤4：对逻辑模型进行物理化；

       （2）集市区：集市区的设计表结构设计主要按维度模型（雪花模型、星形模型）进行设计，主要是为了方便应用分析，满足数据应用需求，集市区一般以切片的形式保留结果历史数据，但保留期限不会太长，比如只保留月末数据以及当前月份的每日切片数据。

       数据集市需要从数据仓库获得基础数据，对于仓内集市，可以直接访问或通过视图访问，减少数据存储，仓外集市则需要从数据仓库获得批量数据作为基础数据进行存储加工。因此仓外集市还需要设计基础数据的保留策略。

      集市区的设计步骤如下：

       （3）接口区：接口区的设计完全根据数据应用系统的接口方式来进行，一般也是维度模型（事实表+维度表）方式，接口区之前也提到过，不做复杂计算，只做简单关联，可以将复杂计算放到集市或指标汇总层加工。
        （4）指标汇总区：作为集市接口区和主数据区的中间层，主要是提供基于各集市和接口数据的共性需求，基于主模型区数据进行统一加工。即面向所有的应用需求来设计，那中间层一般采用维度模型，按从细粒度到粗粒度的方式逐步汇总。由于各数据应用及集市的需求不断变化，指标汇总区也是不断进行完善，许多一开始在集市的加工由于其它集市或应用也需要，则会从集市转移到指标汇总层。常见的数据就是客户、账户、合同等常用的数据实体的宽表（事实表），统一进行汇总后供各数据应用使用。

        另外指标汇总层也包括共性指标的加工，指标可以通过基础指标配置指标计算加工方式获得衍生指标，那这些基础指标和衍生指标的定义、口径以及加工方式可以由指标管理系统来维护并集成到数据标准系统和元数据管理系统中。

        指标汇总区设计步骤如下：

        （5）非结构化数据存储区：非结构化存储区的设计不仅需要考虑非结构化数据本身的存储，同时需要考虑非结构化数据所带有的结构化属性，因此在设计时主要考虑以下几点：

         1）存储路径规划：是需要将非结构化数据按源系统、类型、日期、外部来源等角度进行存储路径的规划，分门别类，便于管理。

         2）对非结构化数据的元数据建立索引：比如对于凭证的影像，需要有账户、流水号、客户名等相关结构化数据，以便完整描述影像图片的来源，通过对这些结构化数据建立索引，方便查找。

         3）对部分文档内容建立索引：对于部分文档如合同电子版、红头文件PDF需要建立内容索引，以便快速搜索查找文件内容，一般可用支持HADOOP的ElasticSearch来实现。

         4）设立计算区和结果区：由于非结构化数据往往需要使用MAPREDUCE或程序化语言进行处理，也会产生中间临时文件和结果数据，因此需要规划计算区和结果区来存放这些数据。
        （6）历史数据存储区：历史数据区作为历史数据的归档，即包括结构化数据，也包括非结构化数据，对于历史数据除了存储也需要方便查找，历史数据区的规划设计需要考虑非结构化数据存储区的存储、索引设计外，还需要考虑以下几点：

        1）压缩，由于历史数据使用频率低，可以选择压缩率较高的算法，降低存储空间。

         2）容量规划：由于历史数据归档会越来越大，因此需要提前进行容量规划以及历史数据清理。比如10年以上的数据进行删除。

         3）可设计一个管理系统对历史数据进行归档、查找以及管理。
        （7）实时数据区：实时数据区需要使用部分批量数据来和实时流数据进行关联加工，因此可从主数据区获得所需要的数据后进行存放在实时数据区的关联数据区，同时对于加工结果不仅可以推送到KAFKA等消息中间件，同时也可输出到实时数据区的结果区进行保留。
        （8）在线查询区：在线查询区主要在线提供计算结果查询，常用HBASE来实现，设计按照接口来分别存放到不同的HBASE表，字段内容也主要是接口字段内容。HBASE表可以根据应用或者接口类型进行分目录和分用户。由于在线查询区和实时数据区考虑到作业的保障级别以及资源竞争，往往会单独建立一套集群，与批量作业集群进行隔离，在线查询的结果计算可以在批量集群计算后加载到在线查询区。
        后续将分别对主数据区、集市及汇总指标层模型设计进行介绍，敬请关注。

银行系统如何选择专业存折打印机

经过近半个世纪的发展，虽然喷墨、激光打印机发展势头强大，也得到了普及应用，但针打并没有因此而退出打印的历史舞台。相反，随着国家经济建设的高速发展，针式打印机在各行业的应用更加深入和广泛。象金融、税务、保险等有特殊要求的行业领域，都有针式打印机的身影，如票据打印机、存折打印机、条码打印机等针打产品都在这些领域有着广泛的应用。究其原因，还是因为针式打印机所具备的差异化特征决定了其在行业中的运用。例如打印多联的票据，喷墨和激光打印机就难以应对，而针式打印机具备的多联拷贝和连续纸处理能力，就非常适用于各种票据和凭证的处理。各行业的窗口和柜台服务都需要处理大量的票据，针式打印机以低廉的打印成本和对环境的适应能力受到行业用户的欢迎，成为人们的好帮手。 由于行业领域的不同，针式打印机根据行业的应用不同也得到了更加深入的细分，如存折打印机在金融领域的使用就非常普遍。存折打印机是银行柜员应用在柜台上处理存单、票据、凭证的专用打印机。勿庸置疑，其处理存折的数量比较多，相对于其他的针式打印机来说，它在打印厚度上有一定的要求，其打印厚度在2 mm以上，而一般的针式打印机只能处理小于0.84 mm的打印厚度。银行柜员的操作以一个人每天平均处理200笔业务计算，需要打印的存折、票据量就不少，其工作具有很强的重复性强，而且要不断更换存折、票据、凭证等各种打印介质，所以对打印机的要求就需要具有能降低劳动强度、使用方便等特点。尤其是在打印存折时，打印机必须适存折厚度的变化，所以要求存折打印机具备全程自动测厚、自动对边及自动测纸的功能。 随着金融领域信息化的发展及自动化程度的不断加强，使用的打印机也不断更新换代，从发展历程来看，经历了四个发展阶段。第一个阶段是在80年代初期，银行操作还停留在以大量的手工操作为主，逐步向电子化操作过渡的过程中，普通的票据打印机担当着一部分柜员的工作，但在打印的厚度、打印的速度及处理能力方面还远远达不到人们的要求，并不能帮助人们处理更多的业务，更多的工作仍需要人工进行处理。纵观现在大大小小的银行，目前几乎已经没有人还在使用这类打印机了。第二个阶段是具有一些智能化功能的票据打印机应用在金融领域。由于普通的票据打印机越来越不适应银行工作的需求，也为了提高使用者使用打印机的方便性，具有自动纠偏、全程测厚功能等一部分智能功能的票据打印机在银行得到应用，它大大减少了人工工作量，给人们的使用带来了一定的方便性。第三个阶段，专业的存折打印机出现，其智能化功能已经大大提高，在打印速度和质量方面都有明显提升，银行工作人员的使用方便性也得到了很大的提高。但其智能化功能还不够全面，在某些方面还需要手工操作，如：进存折的区域必须是指定的区域进纸，在指定区域才能进行纠偏，限制性还是比较强，银行柜员的工作效率还不能达到最佳。目前已经有不少银行使用了以EPSON PLQ20K为代表的新一代存折打印机，推动整个金融领域打印机的使用进入了第四个阶段：新一代存折打印机时代。 由于银行柜员要处理大量的业务，提高其工作效率，减少手式劳动就成为必要的。新一代的存折打印机（PLQ20K）智能化程度更高，具有自动纠偏、自动测厚、自动对边等智能化功能，使人们操作起来更省心。其次，新一代存折打印机在功能及性能的设计方面都有很大的提升，如PLQ-20K在打印速度方面比一般的存折打印机提升了30%，大大提高了工作效率。其标配三种接口设计，令打印机使用起来更加方便。它还全面兼容目前银行系统的存折打印机控制命令，通过简单易用的设置，使用户可以根据系统环境情况，轻松进行选择。值得一提的是， PLQ-20K人性化设计的存打助手选件包，其后部导纸器垂直方向导纸通道和顶部纸盒的设计，有效节约了工作空间，同时也使工作环境更加整齐。这也成为这款打印机区别于其他打印机的最突出点之一。

银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持，需具体

在整合过程中，建设核心业务系统成为一个新热点。此时，国内银行建设核心业务系统面临两种选择：一是自主开发，二是整体引进。承载着打造“后发优势”及快速与国际接轨的梦想与希望，国内一些银行纷纷走上整体引进之路。 然而，在具体实施过程中，“引进一套国外系统，复制一家一流银行”似乎只是一种理想化的设想。实施国外核心业务系统项目后，国内银行往往投入大量资源，花费大量时间，项目实施计划一改再改，上线时间一推再推，系统却还是不能投入生产。有些银行经过一到两年的探索和尝试，最终还是放弃了国外产品，掉过头来转向国内IT厂商提供的软件。 将国外系统移植到我国银行现有的生产关系环境中，“空气、阳光、土壤、水份”等都大为不同，如果系统的灵活性和适应性不强，结出的果子自然亦非当初所设想的样子。是南橘北枳，中国的银行完全不适于采用国外的系统？或仅仅是水土不服，只要经过本地化、客户化的改造后，国外系统还是能发挥其应有的效应？业内外人士都在密切关注———国外银行核心业务系统在中国实施本地化和客户化的难点究竟在哪里？ 引进国外银行核心业务系统产品，购买只是简单的第一步，如果不经过大量的本地化和客户化工作，系统根本无法发挥其功效。不同类型的国外软件在本地化和客户化过程中会遇到不同的问题。纯技术类软件主要面临技术问题，管理类软件除了技术问题外，更大的困难是文化、体制的差异。整体引进国外银行核心业务系统，虽然遇到很多技术问题，但根本原因还是在于国内外监管环境和体制流程方面的巨大差异。 国外核心业务系统本地化和客户化是一项复杂的系统工程 很多人存在这样一个认识误区，认为软件本地化就是软件翻译，软件客户化就是按照客户需求加以修改。实际上，软件本地化是将一个软件产品按特定国家、地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动；软件客户化是指在分析用户需求与产品差异的基础上，在满足客户需求和保证系统结构稳定的前提下，对软件进行的一系列开发、测试活动。因此，国外软件本地化是一项复杂的系统工程，不是一个简单的从外语到中文的翻译过程；客户化也不单单是按照客户需求去修改系统，否则就失去了购买成型产品的意义。 国外银行核心业务系统在中国的本地化，主要包括本地化界面、国内环境接口、本地化报表、本地化文档及培训等方面。界面本地化包括：语言的汉化，将系统界面中的画面、菜单、操作符、提示信息等要素用中文进行表示；界面的易使用性，针对国外产品操作界面与国内风格的不同，通过适当修改、简化或进一步细化成一个容易使用的操作界面；用户操作习惯的满足，根据用户在旧系统上形成的较好的操作习惯，实现系统对应内容的差异最小化。 与国内外环境的接口：包括人民银行现化支付系统、中央国债登记结算公司接口、上海证券登记结算公司接口、外管局国际收支申报系统、人民币大额和可疑支付交易监测系统、人民币交易系统、结售汇系统、进口品报关单检查和进口单位名录系统、各种本地数据交换信息接口等。 本地化报表：国外核心业务系统报表功能高度参数化，因此报表本地化与报表的具体形式关联性并不十分紧密，工作量主要集中在内部数据的采集。 本地化文档及培训：本地化文档包括用户手册，操作手册、技术手册等；本地化培训，包括详细客户培训、详细设计培训、技术标准培训等。 国外银行核心业务系统在中国的客户化，主要包括需求差异分析、与内部系统的对接、第三方提供功能的集成等三个方面。需求差异分析是以国内银行现有业务或预期目标为基础，对照国外金融IT产品进行功能性分析，找出差异以及应对策略的过程；与银行内部系统对接要分析清楚现有系统与即将开发的新系统之间的详细关联关系，保证新旧系统平稳衔接；第三方提供功能的集成，是指在保证第三方提供的系统运行正常的基础之上，考虑与核心系统进行集成。这一般是由国外厂商在当地IT公司中选中的一家总集成商来完成。 国内外银行监管环境的巨大差异增加本地化难度 国外银行核心业务系统模块多、规模大，业务范围涵盖银行业务的方方面面，其本地化和客户化过程对任何国家的任何银行而言，都不亚于一场革命。把它放到我国银行的背景环境之中，矛盾就会更加突出。我国金融市场化程度不高，监管框架、相关法规制度与国际标准还存在较大差异，银行治理结构的缺损、内部经营管理体制的僵化，操作方式落后，这些都加大了核心业务系统本地化和客户化的工作量。 监管环境和相关法规是硬约束，为适应国内的财会准则以及人民银行、银监会等监管机构的监管要求，国外的核心业务系统必须做出适当修改。此类差异主要体现在以下几方面： 国内外利率管制程度不同，系统在国内本地化和客户化时，某种程度上要牺牲系统的先进性。在国外核心业务系统中，利率就象一个魔方，其多维、立体的参数设置和组合，在打通银行及相关混业领域、联贯各产品方面发挥着灵活的作用。 在国外发达的金融市场环境中，利率作为最核心、最重要的交易要素主要体现在价格功能。国内现阶段金融市场尚未完全放开，利率很大程度上是金融监管当局的管理工具。按照人民银行的利率管理办法，对于各种类型的存款或贷款，利率要求都不尽一致，特别是针对部分种类的存款和贷款更有特殊的规定。国内监管部门利率规定繁多，利息计算方法复杂，因此产生很多差异。这些差异应该按监管规定进行修改，但考虑到修改量太大会影响其稳定性，需要采取折衷作法。 国内外对外汇管制程度的不同，造成核心业务系统本地化和客户化时，系统修改的难度和工作量加大。在外汇管制的背景下，结售汇是我国监管框架下的特殊业务。根据外汇局外汇管理的有关规定，每笔结售汇业务都涉及到：对客户是否在其“名录”中进行真实性的审核；需要对其贸易必备条件进行逐笔、逐级进行审批；还要进行询价、头寸申报、买卖外汇、结算、售汇报表等。国外由于外汇自由兑换，没有哪个模块有类似功能。如果走定制开发模式，可以考虑单独设置结售汇模块。但对国外核心业务系统而言，修改需求介于操作与报表之间，开发起来有一定难度。另外，根据外汇局要求，结售汇报表、大额可疑报表、经常账户报表要直接从业务系统中生成并报送，类似需求对国外系统的改动也很大。 国外系统要与国内支付系统直联，需要对整个模块做彻底的修改。为实现资金清算的STP(直通式处理)，核心业务系统应与现代化支付系统相连接。由于国外系统没有通过国内大额支付系统汇划处理业务的界面，需要按照人行的《中国现代化支付系统与商业银行行内系统接口方案》中规定的报文格式要求，包括支付报文、非支付报文、对账报文等，对系统做大量的改动和测试工作。从稳妥角度考虑，国内银行在建设核心业务系统过程中，一期可以先实现交易驱动账务核算，待系统稳定后再推进清算的直联工作。 国内外会计管理理念和制度的差异，需要重新构架会计体制，实现会计管理的全面转型。国外核心业务系统的会计核算功能，靠交易驱动来实现系统自动化处理。这既是国外系统直通式处理和参数化灵活配置的优势体现，也是实施过程的难点所在。会计核算不仅要跨越管理理念的差距，而且要把大量的制度创新和方案设计的工作想在前头和做在前头。具体来说，就是对所有业务模块驱动会计核算的核算结果通过制度规范想在前面，对上万个会计参数通过严格的确认和配置做在前面，否则会直接影响系统自动化输出的会计核算的结果。这既要求业务归口部门及早改变传统的会计管理模式，又要组织起银行内部技术资源，扎扎实实地做好系统上线前后的各项准备工作。如果会计核算结果的准确性、效率性及安全性缺乏保障或受到置疑，就会动摇整个核心业务系统的根基。 考虑到国内金融改革与银行开放的速度和进程，对上述重大差异要有前瞻性的态度和解决方案。对于接近国际标准、具备中国特色、预计不会成为改革对象、当前必须遵守的法律、法规，要认真对待，研究解决方案。对于事过境迁、含义模糊、明显属于过渡安排、不涉及法律诉讼的制度和规定，可以不予考虑或暂时放一放。另外，在解决方案的方式方法上，要优先考虑适当变通，尽可能地少改产品。按照这样的大原则，才能把修改系统的工作量降到最低。 国内外银行管理体制流程的巨大差异增加客户化复杂度 此外，国内银行经过多年改革与发展也形成了自己独特的管理体制和操作流程。这些管理体制和操作习惯中，大部分来自于经验积累和成绩总结，也有一部分属于不规范的范畴，与国外同业相比存在着一定的差异。有些差异我们已经司空见惯，甚至变成了日常管理操作的一部分。引进国外核心业务系统，要从多个角度思考对这些差异的系统处理方案。 内部核算、清算体制的差异。与国内银行实行的总分行多级核算体制不同，国外银行一般实行一级核算体系，对总分行清算资金往来系统只设一个过渡账户--总分行往来，总分行共用该账户，相互占用资金不计息。因此，国外核心业务系统中没有系统内资金清算功能，总分行不能对开清算资金往来账户。按国内银行的资金管理体制，分行作为一级经营单位，与总行资金往来需要相互计算利息。因而需要开立清算资金账户，用于系统内资金往来。 虽然目前以“集中”和“集权”为主要特征的改革已经成为国内银行的趋势，但这种权利上收和层次减少还限于支行层权力及核算单位的取消，效果尚不十分明显。由于账务层次过多，一些分行内部账交易的数量甚至超过了往来账户，潜在风险加大。不仅占用大量计算机资源，造成系统处理速度慢，批量处理时间长，月终、年终处理压力大，而且也增加了国外核心业务系统本地化和客户化的工作量。 资金管理体制的差异。国外银行由于实行总行一级核算，分行被看作总行的营销前台，客户是银行共同的资源，因此，贷款发放可以简化为银行与客户之间的借贷关系。银行向客户发放贷款属于财务会计核算范畴，由核心业务系统处理；总分行之间的资金占用和利益分配，属于银行内部利益再分配范畴，可以通过外挂的管理会计模块进行核算。而国内银行核算层次多，系统内各层次之间资金关系复杂。有些银行为了加强系统内资金管理，实行了系统内借款的作法。具体执行中要求贷款的发放、回收、计息等均与总、分行间的系统内借款处理绑定关联。此类需求若要在核心业务系统中实现，需要系统做出重大改动。 后督的作法问题。为加强事后监督，国内有些银行实行了后督制度。在手工方式下，后督一般于业务发生次日对原始凭证、会计凭证、审批单和交易流水进行逐笔检查，以此达到对本、外币结算清算和会计核算业务进行逐笔事后监督的目的。国外系统中没有类似我们理解所说的后督功能，如果要实现国内银行现行后督的作法和要求，系统修改的工作量非常大。 “双敲复核”问题。根据会计制度有关规定和风险控制要求，存款、支付、清算所有模块均需增加录入复核功能。即录入员输入交易要素后，由另外的复核员重新录入关键的交易要素，两次录入相符才提交该笔交易。出于降低风险的考虑，国内银行希望能够实现这一功能。但对于国外系统而言，增加双敲复核的功能需要对系统做较大改动，增加处理界面近一倍。国外产品供应商建议采取主管授权和降低录入人员操作权限的方法的方式替代复核功能。由于该项变通处理涉及面广，影响深远，需要分时、分步才能解决。 “倒起息”需求问题。倒起息有时被称作“利率晚到”，指由于某种原因，利率的实际生效日需要提前到系统当前日期之前。国外也有倒起息操作，只不过频率没有我们这么高。目前国外核心业务系统还不能处理好这个问题，完全按照国内银行的自动处理要求对系统进行改造也有一定难度。最后往往选择的是折中的方式：即倒起息在同一结息期内的情况下，系统可以自动计算利差并进行计息；倒起息跨一个结息期时，系统只能提供利息调整数的计算功能，但要手工调整；跨多个结息期时，系统完全要手工操作。还有一种方案建议将利差的计算放在系统之外，通过两个系统自动衔接，实现利息调整批量完成。 重要空白凭证管理问题。国外核心业务系统有支票、汇票、本票的管理功能，但管理层次少，管理内容简单。国内银行要求对银行汇票、银行承兑汇票、银行本票(定额、不定额)、定期存单、来账报单实行总分行多级集中管理，可随时增添票据种类，保留系统对客户的管理，同时需要记表外账(单式记账)。这是国外核心业务系统需要向国内靠拢的地方。 跨分行访问控制问题。国外银行机构设置扁平化，分行只是按业务纵向销售总行产品的前端，因此国外系统一般没有跨分行访问控制的概念，各分支机构间可以随意访问，很多模块无需对跨分行权限进行限制，一家分行可以改动另外一家分行的业务。由于国内银行管理模式与国外不同，因此很容易发生分行错记总行账的问题。即使产品供应商不愿意修改，从风险控制的角度看，类似差异需要按照国内银行现有模式进行修改。 综上所述，由于国内外市场发育程度不同，银行的外部监管环境和法规制度相差较大，银行内部的管理体制、业务流程和操作习惯也有很大的区别。差异是客观存在的，但却是可以靠银行、国外核心系统提供商及国内总集成商共同努力，找到一个彼此接受、合理可行的解决方案。由于差异的解决程度，直接影响到项目的成功与否和风险大小，因此需要各参与方正视差异，共同面对和分担项目风险。这些差异解决好了，就能够实现国外技术与中国实践的良好“嫁接”；解决不好，就会成为“夹生饭”，煮不熟也吃不下。(此文为作者博士论文节选 关于银行系统接口设计和银行系统架构设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 银行系统接口设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于银行系统架构设计、银行系统接口设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。