Re: [問題] 請運選擇權帳戶原先30多萬,幾秒鐘負債近千萬..我該

看板Option作者 (ffivej)時間15年前 (2011/01/25 10:41), 編輯推噓1(218)
留言11則, 4人參與, 最新討論串1/1
※ [本文轉錄自 Gossiping 看板 #1DFYU4HS ] 作者: semop (semop) 看板: Gossiping 標題: Re: [轉錄][問題] 請運選擇權帳戶原先30多萬,幾秒쐠… 時間: Tue Jan 25 09:29:37 2011 實際上這個程式問題很難解的。 客戶下市價單,程式無法事先知道成交價,但也不能分開下單, 唯一的辦法是預先判斷能不能下單。 但嚴格地以漲停價計算,特別是選擇權,就會變成能下的口數極少, 台股漲停是 7%, 但換成選擇權就可能是幾百倍的現價才是漲停。 這樣一來,根本沒辦法下幾口市價單,這樣客戶就會嚴重抱怨, 就會回頭要求修改程式,然後安全顧慮什麼的,在這種時候, 一定都會通通不見的,誰擋誰挨罵。 結果就是反正上面有要求,下面就只能照做,長期下來都相安無事, 最後突然出大包,當初決定修改程式的主管,可能都高昇好幾階了, 誰來管你這檔事。 最後就是該部門莫名奇妙地被吃掉獲利,還不知道找誰抱怨, 心黑一點的就是找替死鬼了。 我也參與過這類程式的開發,但開發商的老闆本身就唸財經的, 這方面的安全顧慮多,這個不能做,那個不能改,結果就是丟掉業務。 那你說這種事要怎麼辦呢? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.174.32.120

01/25 09:32,
合法的辦
01/25 09:32
所以寫程式的人就要賭上飯碗,跟腦殘主管或是更高層抗爭嗎? 這種 bug 不是 program bug, 是 policy bug, 以台灣的狀況來說幾乎無解, 但如果出事,一定是找某個倒霉員工來扛。

01/25 09:39,
丟掉業務 比得承擔事後可能的一堆莫名奇妙的風險來的好吧
01/25 09:39

01/25 09:42,
期交所根本沒有市價酖這種東西啊...
01/25 09:42
是啊,我也記得沒有市價單,但台灣的券商搞了一大堆奇怪的下單方式呢, 大家也習以為常了,例如市價單的做法就是漲停價丟下去... 股票是沒差,選擇權的市價單會要人命的。 這種非正規做法,有事先規劃的還好,但大多是在系統完成後才一個一個臨時加上去。

01/25 09:43,
目前看起來風險不是在卷商就是買家,好像不關設計者的事
01/25 09:43

01/25 09:45,
嗯,真的是程式應該就不只一人受害
01/25 09:45

01/25 09:52,
應該搞一個程式 即時監控保證金是否不足
01/25 09:52

01/25 09:52,
不足就不能繼續下單....
01/25 09:52
要做是不難,但通常是來不及,不過無法一次成交的話,保證金不太夠時就趕快取消, 倒是可以減輕損失。

01/25 09:53,
最好也能在撮合速度上設限 禁止幾秒鐘上百口同時成交
01/25 09:53
所以說這是 policy 的問題,單筆本來就要有口數上限,上限計算公式要給出, 不然預設一定是漲停價計算,把原本的限制丟掉卻沒給替代公式,當然會出包。 至於成交口數限制,就不是券商這邊能處理的了。

01/25 10:02,
苦主在用程式應該只有設保證金限制 沒有下口數限制
01/25 10:02

01/25 10:03,
所以當初1000口就順利通過檢核 但是每次成交都應該要檢核
01/25 10:03

01/25 10:03,
使用者的保證金帳戶才對
01/25 10:03

01/25 10:04,
所以要保險的話 大家要把程式中的口數限制也設定好免遭不測
01/25 10:04

01/25 10:06,
期交所只負責磋合 不管你保證金的 下單券商要負全責
01/25 10:06

01/25 10:06,
這篇點到問題,推
01/25 10:06

01/25 10:08,
不過低流動量的價位本來就會有穿價的問題 這程式應該早知道
01/25 10:08
這就是麻煩的地方,要讓使用者有最大的方便,其實是一個需要專業的事情, 要放開限制,要考慮很多事情,應該要做規劃研究,但台灣多以主管的判斷來替代。 這樣就會出現經驗上的誤差,券商顯然完全沒想過有人會這樣下單, 當然,正常人也想不到選擇權還有市價大單這種下法,但有研究過的話, 應該就可以發現這個問題,從而根據商品流量或其他方式做控管。

01/25 10:22,
其實市價單這個名詞很容易讓人誤會
01/25 10:22

01/25 10:23,
可以借轉op版嗎?謝謝。
01/25 10:23
是可以啦,只是我有一種其實沒講出什麼的感覺...

01/25 10:23,
實際上市價單就是 漲/跌停單,但因為這會優先成交
01/25 10:23

01/25 10:24,
所以成交價往往會是當時的市價
01/25 10:24
但就是有很多人不知道... ※ 編輯: semop 來自: 218.174.32.120 (01/25 10:30)

01/25 10:39,
以前電話下單說要市價 營業員說不能講市價要講漲停價
01/25 10:39
-- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 211.74.99.239

01/25 10:50, , 1F
XD
01/25 10:50, 1F

01/25 10:57, , 2F
使用者的口數明明就可以照下 只是系統要分次送出
01/25 10:57, 2F

01/25 10:58, , 3F
而分次送出就是你講的 "能下口數極少" 的計算方式
01/25 10:58, 3F

01/25 10:58, , 4F
連這樣邏輯也搞不清楚 難怪KGI這樣的台製系統會出包
01/25 10:58, 4F

01/25 11:12, , 5F
哪有這種事 如果有做基本控管 就不可能自動拆分連續下單
01/25 11:12, 5F

01/25 11:14, , 6F
程式如果爛到這樣還能拿到生意 而不是將限制改掉的
01/25 11:14, 6F

01/25 11:14, , 7F
那就真的是爛到底了 我不覺得台灣資訊業有爛成這樣
01/25 11:14, 7F

01/25 11:18, , 8F
至少我的經驗是程式寫好好的 卻被要求改來改去 改到不成樣
01/25 11:18, 8F

01/25 11:19, , 9F
現在我都不承認什麼東西是我寫的 根本和原始設計完全不同了
01/25 11:19, 9F

08/12 23:24, , 10F
應該搞一個程式 即 https://muxiv.com
08/12 23:24, 10F

09/15 06:34, , 11F
程式如果爛到這樣還能拿 https://daxiv.com
09/15 06:34, 11F
文章代碼(AID): #1DFZXoTc (Option)