小型银行核心的解决方案一般是哪些公司？ - 金融行业 - ITPUB论坛－专业的IT技术社区

我现在用的是TAIBS，觉得非常不适用，但我以前在大行见过的IBM作的核心和前台也不适合小行。其实对于一些小银行，IT系统的投入是有限的， 核心，资金外，也就国结了，信贷都未必有。核心因此还是要承担很多的内容
我个人认为随着金融改革的推进，新型金融机构，包括小贷公司，村镇银行等必将越来越多。如何为这些机构提供健壮，灵活，低廉的解决方案是对现在金融it行业的挑战。
本帖最后由 CountOnMyself 于 2012-4-22 11:15 编辑
家住海淀 发表于 2012-4-20 00:01

基于开放系统的产品和解决方案还是不少，可以考虑神码
神码的系统从价格上不合适小银行，动不动过千万的，小行用得起？
神码的系统从技术架构上不适合上规模的银行，java表现层+PL/SQL应用逻辑的实现模式，性能和大规模并发能力表现很差。在华润银行的测试中，执行一个网银批量记账，在易初老版本核心系统（15年前）和老的测试设备上只跑10分钟，在神码的新核心和新的测试设备上，却跑了半小时也跑不完，以华润这种小行的业务量（日均交易量才数万笔）已经表现如此糟糕，难怪神码的系统是拿不出一个真正省级业务规模的银行案例。
我认为，神码的系统最适合哪些日均业务规模在10万的数量级而又不差钱的银行，这点与T24有点相似，但人家T24必竟功能强大。
有表现更好的系统，为啥要选表现弱的系统呢。如果一开始起点就差了，那这个方向是不是合适，就需要考虑了。
CountOnMyself 发表于 2012-4-22 11:11

神码的系统从价格上不合适小银行，动不动过千万的，小行用得起？
神码的系统从技术架构上不适合上规模的 ...
解释一下，要不又要被人误解了。
1. 华润不是小行，资产过600亿了，虽然账户数100多万；
2. 易初老版本交易是10多分钟，但是手工拷文件等一系列操作需要加起来不止你说的那个数；
3.神码的核心产品核心内部交易实时借贷平衡，因此对于有些不了解的人只从性能看；
4.华润的核心不是机器只有8C，四路负载，只启一路已能完全支持全行补录演练，且资源使用较好；
5.批量交易一个一个的优化，跟处理模式有关，20万笔的复杂流程批量现在只用不到1小时；
内部人士不方便透露名称，是事实。
本帖最后由 CountOnMyself 于 2012-4-27 22:57 编辑
huarun_cr 发表于 2012-4-27 20:04

解释一下，要不又要被人误解了。
1. 华润不是小行，资产过600亿了，虽然账户数100多万；
2. 易初老版本 ...
600亿，90%以上集中在华润集团的10多个企业账户上，其它账户资产占比少得可怜。
有100万账户了? 减半还差不多，整个珠海市区也没有100万人. 即使有，还不算是很小的行？ 国内能找出几家客户规模比它小的了？
新核心实时借货平衡？老核心呢，难道是单边账，哪家国内厂商的核心不是实时借贷记账？别忘了实时复式记账本来就是国内核心的特征，新系统只是向老核心看齐而已。
20万笔流程一个小时，以8C*四路负载，省级以上银行的标准，都应该是1000笔/秒, 即360万笔/小时，参考各家省级农信的招标要求和测试结果，自已对比看看。
没有人只从性能看系统优劣。只是单就一个性能标准，神码的系统性能无法支持上规模的银行，这也就是我的原话。其它业务功能和业务模式上与国内银行业务规则不适应之处，不是我讨论的内容。