楼主: 降龙十八掌

[精华] 信息审计的案例分析(每周一论)

[复制链接]
论坛徽章:
0
11#
发表于 2003-5-9 21:33 | 只看该作者

我的想法

我想这样是否可以控制!

drawing1.jpg (16.74 KB, 下载次数: 890)

drawing1.jpg

使用道具 举报

回复
论坛徽章:
0
12#
发表于 2003-5-9 21:35 | 只看该作者

错了!不好意思

这样就可以了

drawing1.jpg (16.74 KB, 下载次数: 882)

drawing1.jpg

使用道具 举报

回复
论坛徽章:
0
13#
发表于 2003-5-9 21:38 | 只看该作者

贴错了

不好意思

21.gif (10.17 KB, 下载次数: 869)

21.gif

使用道具 举报

回复
论坛徽章:
0
14#
发表于 2003-5-12 12:39 | 只看该作者
就我的理解,一般的交易系统中的委托业务都是作为一个transation来处理的,所以委托单应该是不会重复的。
而委托的报盘是独立于委托的,实际设计中也是一个transation,只要报盘了,委托的状态就会改变,如果当机之后的恢复,操作把报盘标志修改了,则会发生重复报单现在。

如果客户是通过柜台委托,则有可能出现柜台操作人员认为没有成功,再次输入委托,这样委托将有两条记录。系统也会产生两条委托回单,操作员可能只让客户接收一张回单,

总之我觉得责任在券商的误操作,而不是系统漏洞。

使用道具 举报

回复
论坛徽章:
0
15#
发表于 2003-5-12 15:24 | 只看该作者
Z小姐问:目前这种说法是否成立?
如果不成立,继续追查这个问题;
如果成立,查其他问题。
对于这个案例,你有什么看法?作为外部审计师应该采取什么行动?内部审计师应该采取什么行动?上述业务流程存在什么问题?
----------------------------------
这种说法当然不成立。
营业部流程的问题,不可能让客户来买单。
首先从技术上说,请大家注意,这里是通信系统故障。一般的营业部只有两种主要的服务器,1.行情服务器 2.资金服务器(一般的委托是通过资金服务器验证的,不知道现在的架构有没有变化)。客户的委托经资金服务器验证后,一般是直接传输到交易所撮合的,交易系统的transaction是不会就同一个委托交易两次的(如果是,那就是交易所的责任,根据我和上交所技术人员的交流,此概率等于零)。所以唯一的可能是委托传输了两次,这说明营业部委托系统或者委托流程存在很大的问题。
第一,没有传输验证机制。
第二,没有成交验证机制。
第三,成交金额和客户剩余资金没有验证,根据中国证监会的规定,营业部不能为客户提供透支,这是违法行为

其实,现在很多券商都在搞数据集中,这是由于他们很多营业部的应用程序不统一,给统一管理带来了很多问题。其次,客户的资金都在营业部,不能跨营业部交易或者交易的数据没有实时性。

使用道具 举报

回复
论坛徽章:
1
ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41
16#
发表于 2003-5-12 23:08 | 只看该作者

个人观点

我认为该营业部对故障的解释是成立的。此通迅故障应该是发生在交易完成后返回“交易成功标志”的过程中。虽然在服务器上的交易已成功,但“交易成功标志”并未成功返回到客户端,造成客户端误认为交易未成功而重复操作。解决的方法可能有两种,一是在客户端加时间戳,二是将“交易成功标志”分为“交易成功”、“交易未成功”、“未确认(设为默认值)”三种状态,如果客户端的状态为“未确认”时,客户端只请求确认,不再重新发送交易。审计人员的任务应该是对漏洞进行评估,并提出建议。我认为对该营业部解决问题的方法也应提出建议,客户的流失对企业来说也是风险。外部审计和内部审计采取的行动有什么不同请指教。另建议斑竹有什么案例都贴出来,别每周一论了,毕竟时间不多了。谢了

使用道具 举报

回复
论坛徽章:
0
17#
发表于 2003-5-14 18:52 | 只看该作者

我的意见

同意你的关点!特别是交易的检验机制!实际上这个行业的系统已经有10年以上了!技术上是相当的成熟了!所以说技术不会出现问题!

如果事实上出现了这种现象从审计的角度分析我认为!

1,外部审计方面

  重点确定在于用户下单的真实性!也就是取证用户下单的真实信 息.

  A:纸质的回单(交易所现场下单时取得交易回单):
         
B:凭交易的合同号网上或其它非现场交易所交易时)查询下单的信
   息

只要能证明如果能证明用户下单的信息于实际的交易结果不一致的话用户可以要求交易所对交易的结果负责.

2.内部审核方面:

  1)着重从于实现交易条件的相关数据表或数据存贮对象的控制下
    手.
    2)以下是我个认为的控制点
    A:用户的Password的安全控制,确保Password的安全性.否则的话
      用户可就惨了!
    B:对客户下单信息的安全控制!
        C:对股票帐户信息的安全控制!
        D:对资金帐户信息的安全控制!
    3)加强对下单模块的逻辑控制最大程度上防止录入错误!如下单的信息于客户的股票帐户,资金帐户,及"历史交易习惯"(分析模型不考虑运行的效率)


以上是本人的观点!本人非机算科班所以以上一些观点见笑之处!批评时留一些面子)

使用道具 举报

回复
论坛徽章:
0
18#
发表于 2003-5-14 19:00 | 只看该作者

补充一点!

刚刚重新看了一下主题!

依据证交法!交易所不得从事融资及融券交易!所以说如果交易所所说的是事实那么至少在交易事务的检验条件方面有缺陷!
同时就算客户是下了两手交易交易所也应该承担重大过失责任!

使用道具 举报

回复
论坛徽章:
0
19#
发表于 2003-5-14 20:43 | 只看该作者

经了解!这种情况是可能出现的!

跟一个交易所的朋友谈了一下!他说最最近他们就出现了这种情况!~后果由交易所负责!关于以下问题说明!


1、融资交易的控制是在下单时的控制!也就是客户下单时控制。
2、交易检验不会检验这笔交易是否是已经交易的。及相关的数据关联控制的。

使用道具 举报

回复
论坛徽章:
0
20#
发表于 2003-5-14 20:55 | 只看该作者

惨!!!!!!!!!

所以说以上分析全他妈的错了!只有检验用户下单的真实性是对的

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表