綠紅黃白黑 » banking http://orson.tw To read. To learn. To think. To share. Sat, 04 Feb 2012 16:14:56 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 破壞者 http://orson.tw/2008/07/07/%e7%a0%b4%e5%a3%9e%e8%80%85/ http://orson.tw/2008/07/07/%e7%a0%b4%e5%a3%9e%e8%80%85/#comments Mon, 07 Jul 2008 03:11:32 +0000 orson http://orson.tw/?p=36 目標：企金客戶
破壞方式： 一站購足式。除了連貸、信用狀、外匯操作這些傳統企金業務。還提供，整體市場分析，營運分析建議（企管顧問）。甚至於上下游廠商串聯介紹及金流平台（B2B）。
複製難度：難
成本結構：高
以台灣的銀行業務去作：未知的東西，沒人願意當第一個。應該還是外商會先做吧，然後本地銀行會嘗試複製，或挖人。

後記
台灣的企金，跟國外的企金還是有很大的差異的。就好像我前面寫的『數量級的差異』。
台灣是以中小企業為主，而這中小企業的定義是資本額一億台幣以下（假設啦）。
而大陸的中小企業，它的定義是10億美元（大陸IBM的朋友說的）。
這兩者在當地國家都是中小企業，但是因為數量級的不同，可以玩或是說需要玩的資本遊戲就不同。
從這個角度看，台灣的銀行可以提供的資本以及資本遊戲的數量、產品豐富度、彈性及深度，當然就遠遠不及其他國家。
所以啊，外商的朋友，別恥笑台灣的企金啦。就算你面對的只是加州的一家小銀行，他也只是在美國算小銀行，但是放眼全世界應該還是排在很前面吧？更何況，加州是美國的創業基地，需要的彈性跟變化程度，不是台灣這幾十年不變的銀行（商業）環境可以比的。
台灣的企金被他們嗤之以鼻，算是剛好。如果這樣能稍微影響台灣的銀行企金走向，就算是賺到了。
您說對嗎？

]]> http://orson.tw/2008/07/07/%e7%a0%b4%e5%a3%9e%e8%80%85/feed/ 0 數量級的不同 http://orson.tw/2008/06/25/%e6%95%b8%e9%87%8f%e7%b4%9a%e7%9a%84%e4%b8%8d%e5%90%8c/ http://orson.tw/2008/06/25/%e6%95%b8%e9%87%8f%e7%b4%9a%e7%9a%84%e4%b8%8d%e5%90%8c/#comments Wed, 25 Jun 2008 00:26:49 +0000 orson http://orson.tw/?p=30 先寫標題

數量級的不同

台灣的系統跟大陸的系統，其中最大的差異，就是數量級的不同

就我本身參與規劃的系統來說。

台灣的核心銀行，目標客戶數600萬到800萬，很多了。但這在大陸只是一個中小型的省的數量，更別說是直管市了，那會上億。

所以相同的系統，相同的功能，從台灣搬過去就能用的？ 除非剛好是地方級。不然，像我客戶那樣，光客戶數就破億，要作系統大集中。有誰能確保自己設計的系統撐得住？

這時候 系統架構的強固性跟彈性的價值才會彰顯出來。
一個客戶端連線會消耗系統多少資源？
沒有做分散式規劃的話，一台機器能撐多少同時的連線？這麼大的機器，客戶願不願意買？
有做分散式處理的話，頻寬要多少？網點要怎樣分佈？整個伺服器群的規劃？資料的即時性？
會有千奇百怪的問題冒出來，這樣，你手上產品的價值還剩多少？要小修、大修還是重翻？
不修不改能給多少人用？留多久的資料？留多少的資料？
修修改改又能吃多少？
重寫，重翻，你有多少成本？客戶付你多少錢？你還剩什麼價值？
這些，不是我們在台灣隨隨便便用一台PC搞定幾百個concurrent connection的時候能夠想像的！
機器是n台，架構的好，管的好的話它的複雜度可能一直都是1，普通一點的是n，而更常見的是n^2。
PM，SA，Arch，DBA這些人都具有規劃得出這樣數量級系統的能力嗎？
就還不用說使用者需求，文化，法律等等的差異了。
待續

]]> http://orson.tw/2008/06/25/%e6%95%b8%e9%87%8f%e7%b4%9a%e7%9a%84%e4%b8%8d%e5%90%8c/feed/ 0 CIF Centric http://orson.tw/2008/06/24/cif-centric/ http://orson.tw/2008/06/24/cif-centric/#comments Tue, 24 Jun 2008 09:28:32 +0000 orson http://orson.tw/?p=28 話說 FNS的core banking他的設計架構是以CIF為中心。

所有個產品、額度、關係人、擔保品，都圍繞著CIF。

但是外圍系統不是這樣幹啊。

所以，以相同的觀點來看事情：

既然所有跟核心帳務相關的東西都要先開CIF。

那以下的系統都可以重新設計，以客戶CIF為中心。

1. 客戶影像系統：以CIF、日期、產品做大分類。而不要單單作為獨立系統或是某系統的附屬。這樣所有系統所需要的所有影像都可以做大集中。試想，客戶所有往來文件、申請件、印鑑、擔保品級營利事業登記證等文件都以客戶為中心，所有在有效期內的影像都可以留用，通用。 連CORE要使用，也不會花太大的功夫。

省時，省空間、更省錢。

2. Extended CIF: Core 所保留的CIF資料，叫做『必要的最少』，但各週邊系統都會需要一些不同的其他欄位，不以CIF為中心，加掛一個Extended CIF，實在是浪費啊。

3. 進件系統

4. 催收系統

……

]]> http://orson.tw/2008/06/24/cif-centric/feed/ 0 額度集中控管系統 http://orson.tw/2008/06/24/%e9%a1%8d%e5%ba%a6%e9%9b%86%e4%b8%ad%e6%8e%a7%e7%ae%a1%e7%b3%bb%e7%b5%b1/ http://orson.tw/2008/06/24/%e9%a1%8d%e5%ba%a6%e9%9b%86%e4%b8%ad%e6%8e%a7%e7%ae%a1%e7%b3%bb%e7%b5%b1/#comments Tue, 24 Jun 2008 02:01:55 +0000 orson http://orson.tw/?p=27 Continue reading →]]> 現在的銀行

對於放貸部份

消金 企金 是分開的

而貸款戶跟帳戶又是分開的

如果有 互相擔保

甚至是 企金的集團戶

總額度是多少 用了多少

各級額度限制是多少 用了多少 可不可以平調 或是母公司向下調

各幣種的限額又是多少

如果同時有多個loan account要開立，佔用額度的時候會不會相互衝突或是沒有占到？

這些動作

有些銀行（我不感說是大部分啦） 都是人工操作

這樣的系統 其實不難

只是它會比較消耗CPU

如果設計的夠好 他對帳務主系統的影響也不會太大

這樣一來

所有放貸 外匯 LC 等相關系統 只要作幾個小更動

查額度

占額度

解額度

都改成呼叫額度管理系統的API 來操作

就可以達到 即時 集中控管 的功效

]]> http://orson.tw/2008/06/24/%e9%a1%8d%e5%ba%a6%e9%9b%86%e4%b8%ad%e6%8e%a7%e7%ae%a1%e7%b3%bb%e7%b5%b1/feed/ 4 垃圾信的未來 http://orson.tw/2007/03/07/%e5%9e%83%e5%9c%be%e4%bf%a1%e7%9a%84%e6%9c%aa%e4%be%86/ http://orson.tw/2007/03/07/%e5%9e%83%e5%9c%be%e4%bf%a1%e7%9a%84%e6%9c%aa%e4%be%86/#comments Tue, 06 Mar 2007 18:23:01 +0000 orson http://orson.tw/?p=4 好吧，我有寫過垃圾信程式。
當然，這世界上有幾乎用之不盡的Open Relay跟撥接網路。
所以，還沒有人用下面的拗步。
但是，總有一天，只要退信機制存在的一天，下面這一招一定可以用。
退件垃圾信
================
把收件人放到寄件人，然後，收件人就填個relay伺服器上一定不存在的帳號，以現在的mail server不支援vrfy機制的情況，mail server就會先收，然後退信。
退到哪？ 就是真正要給的收件人啦，同時寄出的server還是完全合法的server喔。

]]> http://orson.tw/2007/03/07/%e5%9e%83%e5%9c%be%e4%bf%a1%e7%9a%84%e6%9c%aa%e4%be%86/feed/ 2 財富管理三部曲 http://orson.tw/2007/03/05/%e8%b2%a1%e5%af%8c%e7%ae%a1%e7%90%86%e4%b8%89%e9%83%a8%e6%9b%b2/ http://orson.tw/2007/03/05/%e8%b2%a1%e5%af%8c%e7%ae%a1%e7%90%86%e4%b8%89%e9%83%a8%e6%9b%b2/#comments Mon, 05 Mar 2007 12:13:45 +0000 orson http://orson.tw/?p=3 先寫標題
1. SFA
2. CRM
3. Financial Planning

更新
以台灣現在的金融市況
應該先做的是
下車機制 也就是停損的監控跟警示，甚至於不正常交易的監控跟警示。雖然台灣的財管，還是以基金為主，也可以說是被中菲電腦幾乎獨佔。但是這一塊的東西，畢竟跟中菲擅長的不同，可以做，有市場，只是要快。
半年內沒成品，就別做了。

]]> http://orson.tw/2007/03/05/%e8%b2%a1%e5%af%8c%e7%ae%a1%e7%90%86%e4%b8%89%e9%83%a8%e6%9b%b2/feed/ 0