求批量平台的相关实施思路 - 金融行业 - ITPUB论坛－专业的IT技术社区

1）各分行做法不同,文件格式不同
2）客户提供文件与银行的文件不相符，难以满足数据格式要求
3）加密文件不可读、不可写，有的文件需可读;
有的加密，有的不加密，存在操作风险
4）身份认证：难以辨别客户的真实意思表示
5）批量开户业务联网核查、开卡、业务开立都由业务人员手工提供清单，大量占用的网点资源
6）批量代收付资金安全问题:
代发户出现对公账户没有到帐，但代发已经发出的情况
3）业务逻辑实现与管理
4）基础的权限、安全、任务、流程配置、日志管理、通知提醒等等
老胡简单的理了一下，发现内容很多
从系统上，文件维护和文件处理可以由单独系统完成，或者逻辑上独立的系统。
文件维护处理格式转换、加解密、前端文件状态显示等等功能。文件维护将文件格式化成比较稳定的格式送到后续文件处理系统上，并且等待消息接收响应。
文件处理平台按照任务种类实现配置化。每个种类的任务可以是采用逐笔入账方式、汇总入账方式、日间方式、日终方式等多种方式，并且平台能够首选一种方式，同时在不同方式中进行切换，例如如果提交的日间类太多，能够按照一定的规则自动转到日终完成。按照任务种类配置表，前处理、处理应用程序、后处理逐笔完成业务逻辑。
我曾经做过几家行的批量系统，每家行的情况都有所不同，我就针对老胡提的问题试着给几点建议，看是否有帮助吧。（内容整理中，晚一点奉上）
我的观点是，可以把整个批量系统分为两部分，一部分是在核心系统上的批量处理部分，另一部分是“前置”部分：
    1、核心系统上的批量处理部分：
     1）尽量将联机处理与批量处理作为独立的系统，避免争夺资源、互相影响；如果不能使用独立的硬件，那么可以挑选联机处理相对空闲的时段来处理批量业务；当然，即使是独立系统也可以分批次处理。
     2）批量系统对外提供有限的、经过抽象的文件接口；根据需要，抽象的层次可以不同；比如工行，提供了转账接口，而某某农信提供的则可能是代收代付业务接口，但是决不能提供“银电通/代扣电费”之类的接口。
     3）批量系统尽量避免对外提供通讯处理接口，即使要提供，也应该严格限制笔数。
     4）可以提供定时批量和联机批量等多种方式，并且可以按一定规则进行切换
     5）批量系统对外提供的批量开户/卡接口，可以包含相关业务标志（比如：余额变动的短信提示等）
    2、“前置”部分：
     1）可以将各分行、客户的文件（加密/明文）录入系统，再按核心的接口生成批量文件；支持指定规则的文件合并、拆分
     2）建立对公客户信息库，同时维护其签约的业务种类、手续费、加密方式等信息
     3）可以集中完成批量开户业务的联网核查操作
     4）提供贷记资金的核对，资金未到位的代发需要授权；建议多采用独立对公账户代发，减少内部账户带来的资金风险
     5）提供企业客户端，负责：客户文件的初步格式校验与转换、加解密、加验签等
先整理这些，大家继续讨论：）