在新交易系统切换上线工作中,“市场就绪”是其中一个重要方面,在该工作推进中,我访问了业内很多著名证券公司与基金公司。通过对众多市场参与者的调查, 并对许许多多不同系统、不同建设和治理方式进行比较和分析之后,编写了本报告,欢迎批评指正。报告组织如下:

一、证券公司典型系统架构
1)核心生产系统
2)客户关系管理系统
3)公司内部管理与业务支撑系统
二、证券公司集中交易系统架构与灾备建设
1)证券公司集中交易系统架构
2)证券公司灾备恢复管理与系统建设
三、基金公司典型系统架构
1)投资研究与投资交易类系统
2)注册登记与销售服务类系统
3)公司内部管理与业务支撑类系统
四、未来发展展望

如果对本博http://blog.sina.com.cn/drwjf内容进行摘 录和转载,请保留本段说明。
武剑锋

一、证券公司典型系统架构
证券公司通过这二十年来的持续发展,内部各信息技术系统之间已经建立了一种“生态关系”,互相依存,互相制约。虽然不同的证券公司采用了不同的命名体系和不同的分类方法,但是从业务类型来分,它们可归类为核心生产系统、客户关系管理系统、企业资源管理系统以及业务支撑系统,一共四个大类。

1)核心生产系统
核心生产系统通常由如下集中交易系统(也称为柜台系统)、理财系统、法人结算系统、三方存管系统、开放式基金代销系统、风险监控以及反洗钱系统、网上交易系统7小类系统构成。

a)集中交易系统
集中交易系统源自最早期的营业部柜台系统,功能囊括:投资者开户、证券交易委托和成交、各种维度的查询。集中交易系统对外与沪深两个交易所的系统接口,对内作为“内核”,与其他各种系统接口。

这里可以看出,证券公司集中交易系统对于“委托”和“成交”这样的业务中最主要的是“路由”功能,也就是俗称的“跑道”功能,然后同时还有资金买空或者证券卖空的“监控”功能,最后而且压力最大的是“查询”功能,根据有关方面的统计,一次委托操作可能伴随着近十笔的查询操作。

对集中交易系统的运行监控和应急处理是证券公司运行的重中之重,而且近年来在系统建设时,温备、冷备、灾备等多层次容灾方面的考虑也逐渐成熟。

b)理财系统
理财系统包括公司自营和代客理财两类用户。QFII业务通常也在这个系统内进行。有部分公司采用的是“复制”一套集中交易系统,然后在权限管理、复核等方面侧重进行增强。而另有部分公司则是通过开发一个独立的系统,然后接入集中交易系统的方式来设计。

c)法人结算系统
中国证券市场的业务组织结构发展方面,从一开始就就是采用“席位”或者“交易单元”作为基本单位来开展实时交易业务,但是同时采用“法人”作为基本单位来开展结算业务。这种结构产生来自这两个业务的基本要求不同。

经常有人询问“清算”、“交收”和“结算”的差别,这些词来自从西方经济运行体系,一种比较常见的说法是:清算对应clearing,交收对应settlement,清算和交收合起来被称为结算。但是很不幸的是,clearing也经常被翻译为结算,以致于概念上屡有混淆。比如中国证券登记结算有限公司的正式英文名称是China Securities Depository and Clearing Co. Ltd.,中央国债登记结算有限责任公司的正式英文名称为China Government Securities Depository Trust & Clearing Co. Ltd。

我先介绍它们在其发源地的含义,clearing统一指代从一个交易达成契约(commitment)到交收(settle)之前的所有动作。总而言之,清算是用来弥补成交(trade)达成速度比交易(transcation)最终完成速度快很多而必须的过程,技术上通常被分割为:成交后处理(post-trading),交收前处理(pre-settlement)和贷方披露(credit exposure)三个部分,用来保证成交可以在买方或者卖方可能无力偿付时,仍能按照市场规则结清。过程包括报表(reporting)和监控(monitoring),风险控制(risk margining),和合并成交到单一的头寸(netting of trades to single positions),税收处理(tax handling)和失败处理(failure handling)。交收settlement本身是一个法律用语,表示财产的授与、让渡。技术上这个词表示证券的交付(deliver),通常与货币同时反方向进行,以满足合同约定。一言概之,清算不发生财产实际转移,交收发生财产的实际转移。

在西方证券体系中,证券本身由于并未全部“电子化”,多年来发行的“实物券”仍在使用,在成交达成和实物券的交付之间可能需要几个交易日。在美国证券市场遭遇“纸面危机”后,促成了DTC(Depository Trust Company)和后来的DTCC(Depository Trust & Clearing Corporation)成立,即便如此,在1987年股灾中,许多投资者在头破血流的止损卖出中,发现交收失败最终导致他们“在海滩上裸泳”。1989年的G30的报告是电子化清算和交收的里程碑。报告中的9条建议使得可以进一步提高交收效率。到2003年,G30再次发表的《Clearing and Settlement: A Plan of Action》中增加到了20条建议。目前,在电子交收系统中,电子交收发生在参与人之间,如果非参与人希望交收,必须通过一个参与人作为托管方。而且通过电子化,也使得证券的交付与钱款的收取可以同时进行,称为DVP。

证券公司法人结算系统所支持的主要业务除了证券和资金清算、资金交收之外,还包括证券存管、证券账户开户以及变更。法人结算系统对外的接口是中国结算公司北京总部、上海分公司与深圳分公司。

d) 第三方存管系统
第三方存管制度的建立是通过把客户的交易结算资金统一交由第三方存管机构存管,来从技术上防范券商挪用客户保证金。核心原理是存管银行只将客户资金的虚拟数据传送给证券公司,客户资金仍然在客户的银行户头中,待客户发生交易后,存管银行再将客户资金与证券公司结算,从而使得客户资金封闭运行。

每一个客户在银行开设银行结算账户AB(Account of bank),在证券公司开设证券客户资金账户AS(Account of securities)。投资者在AB与AS间建立对应关系的过程被称为“存管签约开户”。三方存管系统下要求技术系统支持AB和AS之间的实时同步。

每一个客户还会在银行开设客户交易结算资金管理账户AV(Account of Virtual)记载客户交易结算资金的变动明细,并与客户的AS建立对应关系。该账户不属于银行结算账户,只是一种虚拟的薄记账户。

证券公司还会在银行开设客户交易结算资金汇总账户AC,作为所有AV的汇总账户。该账户属于银行结算账户,可以进行实际的划付。

证券公司法人交收资金封闭运行,证券公司必须在银行预先登记法人交收账户,比如结算备付金账户、基金TA代销清算账户,证券公司法人交收的客户资金划付只能在AC与预先登记的法人交收账户间进行,同时,银行有权依据中国结算提供的法人交收指令对资金划付方向和金额进行核查。

技术系统也要支持存管银行的实时变更或者撤销。通常银行会为客户提供“另路查询服务”,即通过银行渠道实时查询余额和明细,达到独立监控的目的。

交易日中间,“银转证”的过程为资金从AB转到AS,且实时增加AV的余额。“证转银”的过程为资金从AS转到AB,且实时减少AV的余额。在银证互转过程中,系统必须支持对“超时未应答指令”的重发或者冲正,而当重发或者冲正也失败时,采用“兜底”的日终对账后调帐的流程。

在交易日终了,证券公司与存管银行互换对账文件,各自把接口文件与系统内数据进行逐笔对账,并互换对账结果确认文件。

证券公司在日终对客户清算交收完成之后,将如下清算交收文件发存管银行:客户资金交收明细数据表、客户余额明细数据表、客户结息净额明细表、银行资金交收汇总数据表。

存管银行进行“单客户账户平衡监管”,根据客户资金交收明细数据表更新AV中的交收明细记录,根据客户结息净额明细表更新AV中的季度结息明细记录后,计算AV日终余额,并将余额与客户余额明细数据表中的AS日终余额记录进行必对。存管银行还进行“总分平衡监管职能”,所有AV的余额应该与AC余额+预留中国结算的结算备付金+/-下一交收日存管客户待交收款。以上两项监管若发现不一致,需要通知证券公司查明原因。

证券公司完成日终清算及对客户的资金后,汇总轧差计算存管银行全体客户下一交收日到期应收或者应付的款项,向存管银行发送存管银行资金交收汇总文件;然后,在下一交收日的上午,向存管银行发出资金划转指令,由存管银行根据指令在AC与证券公司法人资金交收过渡账户之间进行资金的划转。

在早期,一个客户只能通过一个银行开展三方存管业务,这既是一个单点故障风险,也往往导致客户抱怨对银行服务没有选择余地而流失。从而,发展到后期,银行的角色发展为存管银行和协办转账银行两种,且存管银行可以再进一步细分为主办存管银行和协办存管银行。

值得一提的是,证券公司实时委托受理业务流程在引入第三方存管后,基本不变,客户委托所产生的资金日间冻结和回转只在集中交易系统中进行薄记,两个系统的日间实时耦合程度非常低。

e)开放式基金代销系统
开放式基金业务与股票、债券等产品的交易业务有很大不同,客观地评估,是一种“B2C代销”的业务模式,为此证券公司利用自身的网点为自身的客户提供开放式基金的申购、赎回、清算等业务而建设开放式基金代销系统。

根据监管要求,系统必须支持客户风险等级评估与申购时按照客户风险等级控制功能。而其开放式基金业务发展到后来,“花样”也很多,比如存管方式,可以比照银行定期存单的方式按笔来赎回,也可以按照按份额来赎回;比如折扣方式,可以对不同基金代码不同业务灵活设置;比如交收天数,可以根据不同基金公司的信用,设置不同的延长交收天数;比如根据不同基金公司清算数据到达时间点的不同,设置一日多批次清算。

f)风险监控以及反洗钱系统
风险监控指实时监控公司内部不同分支机构和客户的资金变化情况、客户的交易行为,防止公司自营业务发生超比例持仓、对敲等违规行为。而同时,根据中国人民银行的反洗钱要求,能够从系统采集大额交易和可疑交易行为数据,并完成数据审核、可疑交易数据报送等功能。

风险监控以及反洗钱系统和集中交易系统之间的接口通常采用“异步”的方式,也就是说监控过程不会直接干扰集中交易的主要流程。

g)网上交易系统
因特网是目前最主要的客户委托和查询手段。查询范围除了客户自己的委托和成交之外,还包括公共行情。

网上交易系统在负载均衡方面需要特别考虑,据了解,大部分大型券商采用了在全国多个地点部署网上交易委托系统和行情系统,这种分布式部署即能够为客户提供“就近”的快速服务,也能够通过多个站点都能够支持业务而提高了系统的“容错”指标。

2)客户关系管理系统
与经营其他业务的公司一样,通过技术系统辅助有助于维持与客户的良好关系,所以证券公司必须要加强的第二个大系统是客户关系管理系统(CRM)。

a)凭证电子化系统
实现客户开户影像资料、档案的集中管理,经纪业务、财务会计、资产管理各方面的票据、凭证的电子化。系统实现与影像采集、二代身份证读卡器等的集成,从而大幅提高自动化程度。

通常账户管理采用多层次组织,类似于银行的“一本通”,客户账号作为唯一标识被分配,对应登录密码,用于客户登录时校验。同时,会为客户分配多个资产账号,通常按照营业部分配,资产帐号下再设定沪深交易所账号、场外开放式基金账号以及资金存管帐号等等。

b)门户接入以及呼叫中心系统

证券公司普遍建设门户接入以及呼叫中心系统,通过虚拟网上营业厅,把经纪业务服务网络化,通过与即时通信、短信平台的对接提高与客户的沟通效率。

同时对公司内部,系统提供对客户管理和分析的功能,根据统计数据对客户进行分类、提供客户经理管理功能,向客户推介合适的产品,进行针对性的投资者教育。

大部分证券公司也把经纪人的管理通过系统进行,这些功能同样围绕客户进行,集成到CRM内部或者与CRM接口。

3)公司内部管理与业务支撑系统

内部管理是一个公司的“内功”,而现代企业,通常都会建有企业资源管理系统(ERP)来提升管理水平。ERP系统可以由市售的财务系统、人力资源管理系统、资产管理系统于项目管理系统等集成,也可以独立开发。公文流转以及内部信息系统则是日常办公所有,用来流转签报,发布公告周知等。该类系统与其他行业的同类系统并无本质差异,本文不作特别描述。

另外,不同证券公司的业务有不同侧重,比如有的公司在研究方面有很强的实力,建设有数据仓库、财经资讯等系统,有的公司在投行业务方面有很强的实力,建设有投行业务系统,这类系统由于内部业务使用,称为业务支撑系统。

二、证券公司集中交易系统架构与灾备建设
1)证券公司集中交易系统架构
证券公司集中交易系统通常为4层架构设计,分为:数据库层、应用服务器层、通信服务器层以及客户层。

证券公司在建设时面临一个重要的选择,硬件平台,目前两种主流配置:小型机和PC服务器。如何选择在应用范围上并无定论,通常情况下,规模较大的公司选用小型机,但是也有很公司拥有很多客户仍然选用PC服务器且平稳运行的案例。数据库方面如果选择小型机,通常选用ORACLE或者DB2,如果选择PC服务器,通常选用SQL SERVER。

当前系统设计与营业部柜台系统有很大不同,数据库层只作为“持久化”的设施,而不在数据库内部通过“存储进程”等数据库特定技术来实现业务逻辑。在数据库设计方面最要注意的是,“能否支持按照客户或者按照业务进行拆分?”以便支持数据库处理能力的平行扩展,同时,根据业务特征,历史数据的查询和当日数据的操作也能按需分拆。

由于数据库层中无业务逻辑,所以所有业务逻辑都在应用服务器层中实现。应用服务器层的设计要点是可支持平行扩充,实现负载均衡,同时能够避免技术上的单点故障。应用服务器层中还有一个重要的功能,报盘。报盘方面的技术也经历过技术优化的过程,从早期的数据库轮询方式发展到“队列报盘技术”,能够根据不同业务和客户的类型,采用多通道的方式报盘,并且将回报处理与报盘处理独立开来。特别要强调的是:应用服务器设计时,要求在新业务出现时,能够将支持该业务的服务按照“逻辑”的方式部署到应用服务器层中,从而使得既可以通过扩展服务器的方式扩展,也可以通过在原有服务器上部署新服务的方式扩展。

通信服务器层中也不包含业务逻辑,是比较纯粹的“中间件”,其设计要点是支持平行扩充,可实现负载均衡,同时避免技术单点故障;特别是,由于应用服务器的分布部署,通信服务器层需要具备“路由”的功能。而且,由于通信服务器面对客户,对客户段接入的认证功能也在这个层次实现。

集中交易系统的主要目的之一是为客户提供尽可能多的功能,满足各种不同的要求,特别是在通信服务器、应用服务器分布部署之后,客户端反而要实现“逻辑单一”的接入。成功的客户端的另外一个要点是用户界面的易用性,在此不作缀述。

2)证券公司灾备恢复管理与系统建设
我们首先界定灾难的定义。一般性的灾难事件,是指火灾、爆炸、电力故障、设备故障、网络中断、软件错误、操作失误、恶意破坏等导致生产中心系统无法正常运行,或者卫生、群体事件导致生产中心不可使用的事件。而区域性灾难事件,是指地震、洪水、飓风、大型公共卫生事件、恐怖袭击、区域性通信网故障、区域性电网故障等造成所在地区或有紧密联系的邻近地区的通信、电力、交通及其它关键基础设施受到严重破坏,或者人口不得不进行大规模疏散,导致无法在生产中心维持系统正常运行的事件。

在讨论灾难恢复管理时,通常使用3个指标来衡量:恢复时间目标RTO(Recovery Time Objective),指灾难发生后业务功能从停顿到恢复成功的时间要求。恢复点目标RPO(Recovery Point Objective),指灾难发生后可能丢失业务数据的时间点的要求。运行性能降低预期目标DOO(Degraded Operations Objective),指灾难发生后,与灾难发生前相比运行处理能力的降低情况。

灾难备份中心,是指灾难发生后,接替生产中心进行数据处理和支持关键业务功能运作的场所,包括备用数据中心、备用工作环境、备用生活设施等。形成灾难备份能力还需配备相关业务、技术等人员,并建立相应的运作机制。

备份中心应尽可能地远离主中心,降低灾难波及的可能性。同城灾难备份中心与生产中心之间距离合理,应避免同城备份中心与生产中心同时遭受一般性灾难事件风险的影响;异地备份中心要求距离主中心500公里以上,应避免同城备份中心与生产中心同时遭受区域性灾难事件风险的影响,比如不同的地震带,或者不同的气候带等不同的风险区域。通常有如下4种建设模式:
(一)一主一备:一个生产中心,一个同城或者异地灾难备份中心;
(二)一主二备:一个生产中心,一个同城备份中心,一个异地灾难备份中心;
(三)多主一备:多个生产中心共享一个灾难备份中心;
(四)多主多备:多个生产中心与多个灾难备份中心;

在系统设计上,生产中心的系统与备份中心的系统可以是“逻辑抽象”的,即系统互为备份,物理上任何一个中心都可以根据需要,作为生产中心或者备份中心。主、备中心之间以及与其它数据中心(比如交易所、登记结算公司、存管银行之间的网络应冗余设计,带宽充分,并采用不同的独立通信方式或者通信运营商互联。

如果生产中心和备份中心采用的是“双活负载均衡”的模式,那么由于备份中心平日也处在运行状态下,备份中心的可用性是能够按照要求保证的。但是如果采用“冷备”模式,除了安排定期检查和维护之外,也需要安排对备用中心的定期启用和切换操作的定期演练,保证可用性,而且特别要注意的是,生产系统的各种补丁、更新以及变化应及时更新到备用系统中。

为保证备份中心在一旦发生灾难时可用,通常隔一段时间就安排一次“灾难演习”,证券公司在演习结束后,应及时总结应急响应和灾难恢复过程中的经验教训,评估应急预案的实施效果,对应急预案进行修改和完善。并完成生产系统的回切和状态检查,确保次日生产运行的安全。

不管如何设计灾难备份的方案,“数据离线备份”都是“终极兜底方案”,原因是数据中心可以重新建设,设备可以重新购置,这方面是“无差别”的,然而数据是不能通过重新录入或者重新购买的方式的重新产生,必须是自己进行维护的。所以,应将包括但不限于:客户资料信息、市场交易数据、登记结算数据、客户资金和股份数据及变化数据、财务数据等重要数据备份到介质上,并且介质应实行异地存储,距离500公里以上,并对介质的存放环境、使用、维护、定期盘点和销毁等方面作出严格规定,特别是,需要对介质上保存的数据定期进行有效性的检测,确保备份数据与生产系统相一致,防止介质失效。

三、基金公司典型系统架构

中国的投资基金最早起步可追溯到1991年,而特别在1997年10月中国证监会颁布了《证券投资基金管理暂行办法》之后,由于该办法对证券投资基金的设立,募集与交易,基金托管人、基金管理人和基金持有人的权利和义务,投资运作与管理等都作出了明确的规范,确立了现代基金管理的模式,基金公司核心系统的开发和应用进入了新的时期。

1998年3月,金泰、开元证券投资基金设立,一直到2001年,基金产品局限为封闭式基金,基金公司基本上不需要直接面对投资者,无需市场营销体系,系统功能主要集中在投资研究与投资交易方面。2001年9月,第一只开放式基金成立,基金投资风格逐渐多样化,产品线逐渐完善,而市场营销、客户服务也日渐成为基金公司的重要工作。特别是从2007年之后,随着QDII的发行,基金公司的投资视野一下拓展到了全球范围,对基金公司提出了新的挑战。

面对基金公司的众多应用系统,我们把它们分为三个大类:投资研究与投资交易类系统、注册登记与销售服务类系统、公司内部管理与业务支撑类系统。

1)投资研究与投资交易类系统
这类系统的核心数据是投资数据。包括宏观数据、行业数据、上市公司财务数据、上市公司公司行为数据、行情数据、新股发行数据等信息以及交易数据、基金会计核算数据等等。随着近年来业务的发展,这些数据采集范围从国内证券市场向全球证券市场发展,证券品种从股票、债券向各类金融衍生品发展。交易行为的支持从支持国内证券市场向全球证券市场发展。

a)研究资讯系统
基金公司内部惯用投资前、投资中、投资后来称呼系统的属性。研究资讯系统为投资前服务。这个系统从最初简单的研究报告发布系统发展而来,后来不断集成各类投研信息,可以按照多个不同的主题组织,可以提供搜索功能。

b)投资组合管理系统
投资组合管理系统为投资中服务。通过投资组合管理系统进行风险试算并与程序化交易系统对接,是一个决策支持系统。由于通常从择时能力、行业配置能力以及选股能力三个方面评判和分析研究人员与基金经理的投资能力,所以系统设计时的主要指标体系也是按照这三个方面来建立的。

c)投资交易系统
投资交易系统为投资中服务。投资交易系统源自证券公司的证券交易系统,但是由于在交易指令管理、风险控制、组合管理、合规控制、绩效评估方面需求不同,有着明显不同,比如实时核算交易的成本和盈亏,比如对投资组合的风险进行度量和预警,比如按照设定的指标对基金资产进行分类,比如对基金绩效进行评估等等,所以后期发展差别越来越大。

投资交易系统的另外一个重要发展是“算法交易”的能力。所谓“算法交易”指通过计算机预先设定的算法,由程序自动在瞬间产生一组委托的方法。国际市场上的算法交易系统经历过三代,第一代模型集中在利用历史数据上;第二代模型在继承第一代模型的基础上,考虑寻求成本与风险的最佳平衡点;第三代模型则在第一、二代之上,再通过寻找潜在的暗流资金,挖掘其他参与者隐藏起来的流动性,并且通过在短时间内产生大量相关的委托,先前的委托可以后来的委托取消或者替代,将自己的真实意图隐藏起来。目前国内基金公司尚处在研究算法交易系统,并起步部署的阶段。对于具有QDII业务资格的基金公司,通常是通过引进成熟稳定的海外投资交易系统直接使用。

d)投资绩效与基金估值系统
投资绩效与基金估值系统为投资后服务。范围包括绩效评估、归因分析、会计核算。主要功能包括以凭证录入、凭证查询、检查凭证、凭证汇总表、凭证打印以及审核凭证等凭证管理工作;登账和结账等账务处理工作。

e)风险管理系统
近年来监管法规逐步完善,带来了业务规则的复杂化,而年金和专户业务的个性化合规管理也与普通基金有着差异,为此,基金公司需要建立支持对市场风险、信用风险、流动性风险、操作风险、合规与法律等多方面风险的全面风险管理系统。

系统对组合头寸以及仓位情况进行分析,对资产中不同类型资产配置情况进行风险测量、风险回报分析、业绩对比和业绩归因计算,对监管机构、委托人和公司内部规定的各种限额进行计算和监控,并向用户展示多种维度的结果。

而根据中国人民银行发布《证券期货也大额交易和可疑交易报告数据报送接口规范》的要求,反洗钱数据的提取功能也可纳入风险管理系统。
2)注册登记与销售服务类系统
这类系统的核心数据是客心数据,包括客户账户数据、客户交易数据、客户服务数据、客户分析数据。中国证券市场的“散户”特征即投资者数目众多,对系统在注册登记与销售服务方面的处理能力提出越来越高的要求,而且伴随着投资金额的增大,监管机构对灾难备份建设和信息系统安全等级保护提出了明确的技术要求。

a)注册登记与资金清算系统
注册登记系统的主要功能是对账户进行管理,对持有情况进行薄记,支持发行、过户、权益分配、费用计算等业务的开展。市场上共有两类注册登记系统,一类是由基金公司自建,另外一类是由中国结算建立。

资金清算系统是配合注册登记系统,用于在基金销售过程中对资金的清算、对账、划款和账务管理。根据每日的确认数据和每个机构的到账划款日期,生成应收应付数据,并且根据资金交割模式,计算应收应付的费用,最后生成相关的财务类凭证,和执行电子网银划款指令。

b)直销与网上交易系统
对基金直销、网上交易、呼叫中心三种销售模式,可采用一个统一的直销与网上交易系统来支持,与投资交易系统匹配证券交易所的开市时间不同,直销与网上交易系统都需要支持一周7天,一天24小时的不间断服务。直销与网上交易系统作为一个全方位的销售平台,在支付渠道方面支持多家银行的网银支付扣款,在业务类型上发展出“定期定额申购”、“一个客户多银行卡”等便于投资者的创新模式。

直销与网上交易系统的业务关键还在对零售客户进行精细化与个性化管理、客户洞察与行为细分、事件营销等多个方面。而技术方面重点考虑的是支持在更广的地域上开展代销和直销业务的能力,以及提升用户体验方面。

c)客户关系管理系统
客户关系管理系统CRM是包括营销、销售和服务的业务系统,而基金公司的两大“客户”,一方是渠道,比如银行和券商等代销机构;另外一方是机构,比如企业年金、集合专户理财等机构客户。CRM系统需与注册登记系统、直销系统等有分工有配合。主要对销售流程进行管理,以及对客户进行分析。
3)公司内部管理与业务支撑类系统
这类系统通常由财务系统、人力资源管理系统、资产管理系统等通用系统以及公文流转、电子邮件系统以及协同办公系统等组成。该类系统与其他行业的同类系统并无本质差异,本文不作特别描述。

四、未来发展展望

从调查研究结果来看,目前业内的系统建设还处在蓬勃的建设期,虽然进行了分类汇总,但是实际上,一个公司内部系统的数目远不止这些,而且往往不同的系统由不同的开发商提供,系统之间的接口还处在自由发展阶段,特别是有时候出于竞争的原因,不同的开发商之间会制造壁垒。所以,类似于当年将众多营业部的独立柜台系统整合为一套集中交易系统,我预计未来对这些零星小系统的进一步梳理和集成仍将继续,逐步建立以核心系统为中心,其他系统围绕核心系统,通过标准化接口的方式来构建有机的整体系统。而关于这些系统间接口,我们知道在发达国家证券市场,FIX标准在证券公司或者基金公司内部也都得到了很充分的应用,预计随着交易所与市场参与者接口之间的标准化,也能够推动市场参与者系统内部之间接口的标准化。

而在核心系统的安全生产方面,应急维稳能力、灾难备份能力、等级保护水平、运行体系标准四个要点将是市场参与者重点要关注的。其中应急维稳能力的提升除了在系统建设的时候加强测试等质量保证投入之外,还要通过组织保障、应急预案、危机处理等方面的制度建设和实际演练来提升。而灾难备份能力除了基础设施、技术系统方面的投入之外,必不可少的是业务操作等方面在灾难发生时,也同样具有备份的能力。另外由于市场参与者的网上交易、门户等系统直接通过因特网面向投资者,部分系统暴露在公网上,所以通过等级保护水平的提升,在安全评估、安全控制、安全审计、网络隔离、漏洞扫描等安全措施方面改进和加强,并可参照ISO27001和ISO17799等分期推进。最后,在IT运行管理方面,越来越多的关于“最佳实践”的总结和提炼导致了ITSM、ITIL、ISO20000等规范或者标准的出台,市场参与者需要通过“对标”来落实在内审和管理方面的机制、流程与办法。

技术系统最重要的是能够很好地支持业务创新和服务创新,所以除了从技术架构出发,而需要安排的技术系统整合、优化等变更之外,更要保障的是为支持业务和服务创新而对系统做出的变更。而应对业务快速发展的方法,就是能够简化和精化系统,通过多种渠道提供服务,并且通过在IT治理水平层面的提升,加强业务和技术之间的理解和融合程度。

转载于:https://www.cnblogs.com/timlong/p/5501684.html

交易系统解析(八)证券公司与基金公司系统综述相关推荐

  1. Deep Learning论文笔记之(八)Deep Learning最新综述

    Deep Learning论文笔记之(八)Deep Learning最新综述 zouxy09@qq.com http://blog.csdn.net/zouxy09 自己平时看了一些论文,但老感觉看完 ...

  2. 《预训练周刊》第19期:歧义短语的类量子语境性研究、自然语言处理中prompt方法的系统综述...

    No.19 智源社区 预训练组 预 训 练 研究 观点 资源 活动 关于周刊 超大规模预训练模型是当前人工智能领域研究的热点,为了帮助研究与工程人员了解这一领域的进展和资讯,智源社区整理了第19期&l ...

  3. Cochrane系统综述注册的具体流程

    想做课题但是奈何自己没有数据?科研小白除了可以从公共数据库申请公共数据进行二次数据分析之外,对他人的研究进行分析评价也不失为另一个极佳选择. 本文介绍关于Cochrane系统综述注册的具体流程,希望能 ...

  4. YouTube怎么判断影片内含侵权内容? 解析Content ID内容识别系统的原理及功能

    你有没有发现YouTube上有许多没有声音,或是画面翻转的影片? 这些主要都是为了逃避YouTube全自动的内容识别系统 (Content ID)监测. YouTube为了保护版权影片,发展出这一套强 ...

  5. 机器学习算法在退行性颈椎和腰椎疾病中的应用:一项系统综述

    Utility of machine learning algorithms in degenerative cervical and lumbar spine disease: a systemat ...

  6. 人工智能会话代理在医疗保健中的有效性:系统综述

    #论文泛读 ##The Effectiveness of Artificial Intelligence Conversational Agents in Health Care: Systemati ...

  7. 转载:嵌入式系统综述之二

    发信人: redtiger (红虎), 信区: Embedded 标 题: 嵌入式系统综述之二 发信站: 饮水思源 (2001年11月20日22:07:39 星期二), 站内信件 嵌入式系统综述之二 ...

  8. 【Reference Reading】MRI-only放射治疗的synthetic CT 生成方法的系统综述

    题目:Systematic Review of Synthetic Computed Tomography Generation Methodologies for Use in Magnetic R ...

  9. 互联网广告系统综述五系统架构

    互联网广告系统综述五系统架构 声明: 1)该博文是整理自网上很大牛和专家所无私奉献的资料的.具体引用的资料请看参考文献.具体的版本声明也参考原文献 2)本文仅供学术交流,非商用.所以每一部分具体的参考 ...

最新文章

  1. Bitcoin 中的挖矿算法(5) 难度值举例说明
  2. 《草原安魂曲》《自由意志》及其他我喜欢的电影海报
  3. dataframe常用操作_Pandas | Dataframe的merge操作,像数据库一样尽情join
  4. datagrid显示mysql_WPF DataGrid显示MySQL查询信息,且可删除、修改、插入 (原发布 csdn 2018-10-13 20:07:28)...
  5. HDU 5935 2016CCPC杭州 C: Car
  6. Linux命令学习笔记之 network NetworkManager
  7. mysql数据库服务器默认端口_各个数据库的默认端口
  8. matlab DFA算法计算Hurst指数
  9. 万字攻略全面了解selenium_selenium教程
  10. 关于Python3爬虫抓取豆瓣电影的案例-利用正则表达式
  11. 一道简单的百度笔试题
  12. ConcurrentHashMap的锁
  13. 转载 --史上最全数学符号、公式的英文读法,干货满满!
  14. STMCubeMX+Proteus仿真DHT11(数码管显示)
  15. 步进电机算法s曲线的原理与实现
  16. 在调试的时候碰到了Render process gone.问题
  17. php 数组 时间戳排序,php – 按时间戳排序Summed Collection
  18. Java程序设计(2021春)——第三章类的重用笔记与思考
  19. ubuntu 安装 go 和 go-ethereum 流程
  20. 【PHP】break跳出多层循环用法

热门文章

  1. A股市场全景分析系列—行业板块和热门概念RPS排名
  2. Bootstrap学习笔记04
  3. 重提“不要看《深入浅出mfc》!”一文
  4. JAVA中Action层, Service层 ,model层 和 Dao层的功能区分
  5. 自动化测试框架如果都总结成这样,人人都能学好
  6. 90 岁程序员:他的压缩算法改变了世界!
  7. WIFI基础入门--802.11--直接序列物理层(DSSS)--12
  8. 图文讲解 上网本 无光驱 系统蓝屏/系统无法开机 用U盘 winpe 启动U盘 重装系统的方法(通用PE工具箱/老毛桃/大白菜WinPE)
  9. 【ICML2022】可达性约束强化学习
  10. HBase 数量统计