基金銷售機構(gòu)之建設(shè)基金代銷系統(tǒng)
基金代銷系統(tǒng)
1.1 背景
目前我國公募基金銷售行業(yè)如雨后春筍一般，不僅傳統(tǒng)的銀行券商和獨立代銷機構(gòu)在激烈廝殺，很多P2P平臺、綜合理財平臺也在以各種方式切入這個行業(yè)，價格戰(zhàn)越來越激烈，但產(chǎn)品設(shè)計上也越來越創(chuàng)新，整個行業(yè)還是非常生機勃勃的。
當(dāng)前基金銷售機構(gòu)在建設(shè)基金代銷系統(tǒng)上無非兩種方式：自建，或購買恒生金證等公司的系統(tǒng)加以改造。
下面我從三個方面介紹下一個基金代銷系統(tǒng)：
(1)賬戶體系
(2)基金交易
(3)基金支付
1.2 賬戶體系
我以XX基金的賬戶體系為例，不一定和市面上完全相同，但大同小異。
我們的賬戶體系分用戶賬戶、基金交易賬戶、分銷交易賬戶、資金賬戶、子交易賬戶、基金賬戶。
- 用戶賬戶 : 一個手機號對應(yīng)一個用戶賬戶，用戶使用手機號注冊并驗證通過，設(shè)置登錄密碼后開通。
- 基金交易賬戶: 一個自然人或機構(gòu)開通一個基金交易賬戶，自然人通過身份證、護照等證件實名認(rèn)證，機構(gòu)客戶通過營業(yè)執(zhí)照等證件，認(rèn)證通過后開通基金交易賬戶。基金交易賬戶編號前3位通常是一個基金銷售機構(gòu)的唯一編碼。
- 分銷交易賬戶:因為有外部合作業(yè)務(wù)，XX基金和百度、理財通、鳳凰都有基金銷售合作業(yè)務(wù)，一個用戶可能在多個分銷機構(gòu)開通了基金交易，所以用戶在每個分銷機構(gòu)對應(yīng)有一個分銷交易賬戶。基金交易賬戶 1:N 分銷交易賬戶。XX本身是一個分銷機構(gòu)存在。
- 資金賬戶： 用戶每綁定一張銀行卡，鑒權(quán)通過后生成一個資金賬戶。無論這個銀行卡是在XX綁定，還是在分銷機構(gòu)綁定，這個資金賬號是唯一的。驗卡鑒權(quán)現(xiàn)在基本是通過快捷鑒權(quán)，四要素驗證。以前還是有B2C、小額打款等等、CP驗密，等等現(xiàn)在都不用了。
- 子交易賬戶： 一個資金賬戶和一個分銷交易賬戶，生成一個子交易賬戶。子交易賬戶用途是做基金份額登記。
- 基金賬戶：一家TA對應(yīng)一個基金賬戶。所以基金交易賬戶和基金賬戶是一對多關(guān)系。用戶在XX開通基金交易賬戶，買了5家基金公司基金，就開了5個基金賬戶。基金賬戶是基金公司開通的，我們會在用戶首次購買該基金公司產(chǎn)品時，一起將開戶和認(rèn)申購交易上報給基金公司。同一個人，在天天基金、XX基金購買了同一支基金，他的基金賬號是一樣的。
TA就是Transfer Agent的簡稱，也就是注冊登記代理機構(gòu)的意思，每家基金公司都有這么一個系統(tǒng)，用來給用戶注冊登記基金份額用的。
1.3 基金交易
1. 常規(guī)交易
基金交易通常分兩種，一種是用戶發(fā)起的交易，一種是TA發(fā)起的交易。
- 用戶發(fā)起的交易:常見的包括基金賬戶開戶、認(rèn)購、申購、贖回、快速過戶轉(zhuǎn)換、轉(zhuǎn)托管、修改分紅方式等。
- TA 發(fā)起的交易: 常見的主要是分紅發(fā)放，強制贖回、調(diào)整調(diào)減、清盤等。
這些基金業(yè)務(wù)名稱大都一目了然，而且大家應(yīng)該也都做過些基金投資，我就不一一介紹了。
在代銷業(yè)務(wù)模式下，銷售機構(gòu)和基金公司之間是以文件形式傳遞交易數(shù)據(jù)的。常見的文件有：
- 開戶申請 01 文件、交易申請 03 文件(包括所有用戶發(fā)起的交易)
- 開戶確認(rèn) 02 文件，交易確認(rèn) 04 文件(包括所有用戶發(fā)起、TA 發(fā)起的交易)
- 份額對賬 05 文件
- 分紅下發(fā) 06 文件
- 基金行情 07 文件
舉個例子, 用戶購買A基金公司的基金，銷售基金會在日終清算后生成給A基金公司的03文件，這里面包含了申請該基金的交易數(shù)據(jù)，如果是首次購買還會生成01文件，包含開基金賬戶申請數(shù)據(jù)。這些文件會放到中央數(shù)據(jù)交互平臺，當(dāng)日A基金公司下載文件并處理。T+1日會將申購交易確認(rèn)處理后的數(shù)據(jù)放在04文件里，并放回到數(shù)據(jù)交換平臺。銷售機構(gòu)下載確認(rèn)文件，并且做確認(rèn)清算處理。清算后該給用戶加份額就加份額，給基金公司結(jié)算申購款就結(jié)算申購款。如果有申購確認(rèn)失敗，或者部分成功的情況，還需要給用戶發(fā)起退款。
2. 申購交易
銷售機構(gòu)按金額申請，TA 以份額確認(rèn)。
T 日申請，T+1日確認(rèn)，QDII 基金一般T+2
T+1 日，支付機構(gòu)將申購款結(jié)算到銷售機構(gòu)指定的監(jiān)管銀行歸集賬戶。
確認(rèn)日第二天，也就是通常T+2日，銷售機構(gòu)向監(jiān)管銀行發(fā)起劃款指令，將申購款打到基金公司的注冊登記賬戶。
最后由中登將錢打到基金公司的銀行托管總賬戶上。
3. 贖回交易
按份額申請，以金額確認(rèn)。
T日申請，T+1日確認(rèn)(QDII通常T+2)。
4. 贖回資金
贖回款由基金公司托管銀行賬戶打到注冊登記賬戶。
然后由中登打到銷售機構(gòu)的監(jiān)管銀行歸集賬戶上。
最后由銷售機構(gòu)發(fā)出贖回款劃出指令，打到客戶銀行卡上。
贖回款到賬日視基金類型不同而不同。貨幣基金一般是確認(rèn)日當(dāng)天，股票型基金通常確認(rèn)日后2-3天，QD要5個工作日以上。
另外，監(jiān)管銀行會通過04、06文件核對每一筆給客戶的贖回款、分紅款。
1.4 基金支付
這塊其實大家都很熟悉了，我們一般接入的支付渠道就是第三方支付、銀行直連。估計接了十多家吧。
和一般的電商不同的是，基金交易支付通常是協(xié)議代扣，而不是快捷支付。用戶在綁卡時會簽署代扣協(xié)議，不過有些渠道是信任代扣的，什么意思呢，就是用戶這張卡在A渠道做了鑒權(quán)通過后，B渠道是信任的鑒權(quán)結(jié)果的，無需再做一次鑒權(quán)。
因為業(yè)務(wù)需求，我們在扣款上也做了一些相應(yīng)的創(chuàng)新，比如多筆交易合并支付，用戶購買一個基金組合產(chǎn)品，5個基金原本是5筆代扣交易，合并成一筆去代扣。這在電商系統(tǒng)里很常見，但是在基金交易系統(tǒng)里原本是沒有這種設(shè)計的。
另外還有多渠道組合支付，比如私募基金交易，單筆支付額度巨大，100萬起，我們有點銀行額度是達(dá)不到的。只能采用多渠道組合的方式去代扣。
支付對賬方面，我們做了外部對賬、內(nèi)部對賬：
- 外部對賬，顯而易見是支付系統(tǒng)和支付機構(gòu)對賬，一般是15點收市之后下載對賬文件，對賬交易包含是T-1日15點以后到當(dāng)前T日15點的
- 內(nèi)部對賬，是支付系統(tǒng)和交易系統(tǒng)之間的對賬，涉及到一些訂單狀態(tài)更新、差錯處理、撤單等等。
最后說下資金結(jié)算。申購款一般是T+1 12:00之前結(jié)算到銷售機構(gòu)歸集賬戶，這是有明文規(guī)定的，可以參考《證券投資基金銷售結(jié)算資金管理暫行規(guī)定》。但是贖回款、現(xiàn)金分紅款、認(rèn)申購失敗的退款，一般我們不走支付機構(gòu)，而是由監(jiān)管銀行代發(fā)。因為免費。
好，以上是銀行卡支付的一些介紹。
目前業(yè)內(nèi)比較流行的做法是和余額寶一樣，用貨幣基金包裝成錢包產(chǎn)品，來取代銀行卡支付，將用戶的資金留存在平臺的生態(tài)體系里，同時降低了支付成本。比如用余額寶買股基、贖回基金到余額寶，實現(xiàn)貨基T+0取現(xiàn)，等等。這塊就涉及基金直銷業(yè)務(wù)模式了，一般是直接連基金的直銷系統(tǒng)，后續(xù)有機會再和大家分享。
二、Q&A
Q：只能采用多渠道組合的方式去代扣，這個怎么理解?一筆100萬，系統(tǒng)拆成20筆五萬，發(fā)到不同的支付機構(gòu)或銀行扣款成功?
A：是的，拆成不同的支付渠道去扣款。
Q：扣一半怎么辦?(但是有幾筆成功，有幾筆不成功，怎么處理/部分成功怎么辦?時效性怎么控制?/還有銀行的終態(tài)返回不一致，怎么把控?)
A：恩，這塊的確有這樣的問題。所以我們是先把錢扣到一個類似余額寶的CXG賬戶里，如果錢都扣到了CXG，再拿CXG余額去買私募基金。如果錢扣一半失敗了，交易就不會發(fā)起。
Q：那會產(chǎn)生另一個問題，支付狀態(tài)的最終成功或失敗，可能相對時間較長
A：所以交易確認(rèn)和資金流相對較長。當(dāng)前這種多渠道扣款只是針對私募基金的線上交易，100萬起的，所以小的體驗上欠缺一點是可以忍受的。
Q：不發(fā)起交易，然后會退款嗎?
A：不會退款，錢會存在CXG賬戶里，用戶可以發(fā)起贖回。
Q：QD是什么意思?
A：QDII 基金，投資海外市場的基金。
Q：資金賬號唯一，這個資金賬號是鑒權(quán)銀行卡的時候銀行給的么?
A：資金賬號是銷售機構(gòu)生成的。
Q：那你怎么保證在其他分銷機構(gòu)幫綁定這個卡生成的資金賬號也是相同的了?
A：問題很好，是這樣的，一般分銷機構(gòu)是不能綁卡的，他們只能把銀行卡信息傳給我們?nèi)ソ壙ā€別像理財通這種，比較強勢的會特殊處理。分銷機構(gòu)一般只是個流量引入平臺，他們沒有基金銷售牌照，基金交易和支付還是我們來做的。
Q：私募基金按照你的說法，從CXG里支付，是否意味必須先充值，而用戶是不能直接銀行卡支付的?
A：只有通道額度不夠的時候才會，銀行卡扣到CXG，再用CXG買私募基金。如果通道額度足夠是不限制的。
Q：用戶在綁卡時會簽署代扣協(xié)議，不過有些渠道是信任代扣的，什么意思呢，就是用戶這張卡在A渠道做了鑒權(quán)通過后，B渠道是信任的鑒權(quán)結(jié)果的，無需在做一次鑒權(quán)。 問:走B渠道還需要再發(fā)短信么?
A：我們走的代扣通道都是不需要短信驗證的，那是快捷支付才需要。如果走信任代扣通道，出了盜卡問題，是要銷售機構(gòu)承擔(dān)責(zé)任的。
Q：這個中央交換平臺是誰建立的呢?是不是所有的基金公司TA都要連
A：這個是中登的統(tǒng)一交換平臺，都是要連的。說白了差不多就是個文件服務(wù)器
Q：銀行直連現(xiàn)在都有信任代扣接口的嗎?還是你們接的是第三方支付?
A：銀行沒有
Q：是對接的哪家第三方支付?
A：具體哪家不便說了，抱歉。
Q：做代銷有資金賬戶，需要有支付牌照嗎?
A：這個資金賬戶原來內(nèi)部記賬用的，跟支付牌照沒關(guān)系。
Q：分銷交易賬號跟子交易賬號是不是交易賬號的概念，區(qū)分開有什么好處?是不是二者就是基金交易賬號的概念吧，交易賬號關(guān)聯(lián)銀行卡(資金賬號)，銀行卡又對應(yīng)多個資金渠道?
A：業(yè)內(nèi)有些公司是銀行卡和資金渠道關(guān)聯(lián)形成一個交易賬號，也就是多交易賬號機制。但我們這個不是，分銷交易賬號是在分銷機構(gòu)注冊開戶才會有的，如果沒有分銷交易賬戶，那用戶在多個分銷同時做了交易就無法區(qū)分開了。
Q：那子交易賬號和分銷交易賬號關(guān)系是什么?這塊我不是太理解
A：子交易賬號是銀行卡的資金賬號和分銷交易賬號共同生成的，可以這么理解，我有一張工行卡，我在XX綁了，也在騰訊綁了，因此會有兩個子交易賬號，用來登記這張卡的基金份額。
Q：剛才說的扣款場景，其實有充值余額、資金池的概念了，這個沒事嗎?
A：這個沒關(guān)系，因為我們是扣款買了貨幣基金。
Q：多個渠道扣款失敗的話，不是會留存余額嗎?
A：部分成功的話會，但是錢是買了貨幣基金，所以沒關(guān)系。
Q：買100萬基金，渠道20萬限額，5次扣款，成功60萬，實際留存余額60萬，這60萬不會買基金吧?只會等用戶提出或者再充值購買吧?
A：會買基金的，CXG的底層貨幣基金是實時確認(rèn)的。
Q：我這里問一下，如果發(fā)生剛剛您說的部分成功的情況，是買了貨幣基金的話，那申請?zhí)岈F(xiàn)就是提現(xiàn)到貨幣基金對應(yīng)的銀行卡，這個操作是一次還是跟之前購買的一樣是組合
A：這個就是普通基金贖回流程。沒有金額限制。是一次的，而且贖回資金不走支付渠道代發(fā)。
Q：那就是你們買的時候做了一次包裝，贖回就按照正常來?
A：待回應(yīng)
Q：中登的平臺，在交易鏈條中的核心功能是啥?
A：數(shù)據(jù)交換的作用，另外他們做為監(jiān)管層，會對數(shù)據(jù)做備份匯總及監(jiān)管。
Q：交換啥數(shù)據(jù)? 和支付結(jié)算相關(guān)? 這個沒大看懂，可能還需要消化下。
A：基金公司和銷售機構(gòu)之間的基金交易數(shù)據(jù)交換。
Q：子交易賬號與卡強關(guān)聯(lián)的目的是什么?同卡進出?
A：是的
Q：騰訊和XX是兩家并行的基金代銷機構(gòu)嗎?
A：不是，騰訊理財通接了XX的基金交易，他是XX代銷下的一家分銷，同時XX分銷也是XX代銷下的一個分銷。打個比喻就像是直營和加盟一樣。所以是兩家并行的分銷。
Q：ta的交易賬號跟子交易賬號是一對一的關(guān)系吧?
A：TA的交易賬號就是我前面說的基金賬戶，這個跟子交易賬號沒有對應(yīng)關(guān)系，只和代銷層面的基金交易賬號關(guān)聯(lián)。并且不是1：1關(guān)系。一個人可以買n個基金公司產(chǎn)品，所以是N：1關(guān)系。
Q：ta有交易賬號和基金賬號兩個概念吧。客戶在不同代銷是同一個基金賬號不同的交易賬號吧?基金賬號應(yīng)該是標(biāo)識客戶的吧。可能理解概念不一樣，我說的ta交易賬號應(yīng)該是你說的代銷層面基金賬號;不同代銷機構(gòu)是同一個基金賬號不同交易賬號，用于區(qū)分份額
A：你說的很對，行家。
Q：你們T+0業(yè)務(wù)是否有跟其他理財產(chǎn)品購買打通?這里涉及資金效率的問題
A：這里涉及資金效率的問題保險、資管產(chǎn)品、公募基金都有打通
Q：像保險、資管類的產(chǎn)品，你們一般非交易過戶是過戶到誰名下?墊資方是基金公司還是自己?
A：自己墊資。基金公司墊資一般都是直接打到客戶銀行卡。
Q：是的，基金公司要保證自己在閉環(huán)內(nèi)
A：各行業(yè)也不一樣，跟券商合作一般都是把錢打給券商，哈哈。
Q：特別問一下，這個余額寶25萬上線對你們這個做法有沒有什么影響?
A：這個沒有影響，25萬是余額寶自己的限制。
Q：用CXG的余額去買基金，是先把份額轉(zhuǎn)給代銷平臺，然后代銷平臺替用戶把錢結(jié)算到歸集賬戶，是這樣嗎?
A：CXG買基金不需要份額轉(zhuǎn)給代銷平臺，只要發(fā)起普通贖回即可，贖回成功就幫客戶發(fā)起基金申購申請。在資金流上贖回貨幣基金的錢t+1到歸集賬戶，不結(jié)算給客戶。同時他+1申購交易確認(rèn)成功，t+2再把贖回的錢結(jié)算給申購基金的基金公司。
Q：那是不是有可能購買基金和贖回之間時間差可能只有幾秒鐘?
A：贖回貨基是調(diào)用基金公司直銷系統(tǒng)接口，除非網(wǎng)絡(luò)阻塞否則不會那么久。
Q：可能我沒描述清楚;前面說大額交易資金會先進CXG，購買貨幣基金。如果一個用戶想買私募基金的話，比如先進行CXG充值，這筆錢會先買貨幣基金，當(dāng)100萬到了后，馬上去買私募，那么CXG里要立即進行贖回，那這個周期就會很短，可能一分鐘內(nèi)就完;這個實際情況會這樣嗎?或者貨幣基金的業(yè)務(wù)規(guī)則允許這樣操作?
A：不會出現(xiàn)您說的這種情況，肯定是確認(rèn)后才贖回的。
Q：那就會出現(xiàn)一分鐘前買了上百萬基金，一分鐘后就贖回了
A：不會，在購買私募的時候會生成一筆贖回申請，但是不會立刻發(fā)給基金公司，而是T+1份額過戶了才發(fā)起贖回的。
Q：那你們要墊資很多很多啊
A：一般不需要墊資的，因為私募是有冷靜期的。
Q：CXG的贖回資金如何能進入托管銀行，正常銀行是要核對第三方支付的申購流水，防止洗錢或者非法贈送
A：這個沒看明白。贖回我們一般不走第三方支付機構(gòu)代發(fā)。
Q：就是代銷機構(gòu)把資金打入托管行，托管行也認(rèn)可是吧?CXG在基金銷售平臺外圍，不在體系內(nèi)?
A：no，CXG的贖回資金也是進入代銷機構(gòu)的監(jiān)管銀行歸集賬戶的。
Q：明白了，此CXG也是包裝的貨幣基金，抱歉，前面沒認(rèn)真看
(網(wǎng)友發(fā)散追問)
Q：哥們可以補充一下，說一下基金賬戶購買非標(biāo)類產(chǎn)品的設(shè)計流程?
A：就是底層實際上會進行債權(quán)匹配，比如3C的消費金融，放款給借款人，或者合作平臺統(tǒng)一結(jié)算
Q：購買非標(biāo)產(chǎn)品是不是不需要墊資?資金都是t+1資金交收吧?
A1：如果提交了申購文件，效率就會很低了;而且過戶給平臺，一般對公T+0基金公司都不給玩，除非跟樓主公司一樣，自己先墊資;問題是合作平臺或者借款人也講資金效率，正常最遲T+1就要收款
A2：這個不一定吧，雙方約定交割時間不就成了么
三. 自由討論
3.1 信用卡逾期利息
Q：問個問題，信用卡消費以后，沒有逾期發(fā)生的時候，系統(tǒng)會不會計算每天的利息，還是在逾期以后，才一次性計算之前的利息?
A1：系統(tǒng)應(yīng)該是每天計提利息。到了結(jié)息周期付息收息;貸款和存款每天都會計提利息。計算每天應(yīng)付應(yīng)收利息。
A2：會按天累“積數(shù)”，例如第一天消費100，第二天消費200，當(dāng)前積數(shù)就是400了。按天累，100累兩天就是200啊
A3：百度下循環(huán)利息就好了
3.2 求信用卡各領(lǐng)域分享
Q：信用卡這塊有沒有人組織分享一下 哪方面的都行 這塊好像到現(xiàn)在為止沒看到群里面討論過
A：待回應(yīng)
3.3 同城雙活ZK跨機房
Q：問個ZK的問題，我們現(xiàn)在有兩個同城雙活機房，ZK的數(shù)量比較麻煩，ZK的選舉是要求奇數(shù)的，怕一個機房出現(xiàn)斷電故障，3+2，3+3可能都不太好。集群半數(shù)宕機無法選舉leader 要半數(shù)以上擁護;同城雙活，兩地三中心，之前各種坑爹，光纖被挖，機房斷電;我們機房是光纖直通的，可以類似內(nèi)網(wǎng)看待，ZK會用來做一些配置集群，包括DUBBO;主要是DUBBO要用，然后開發(fā)了一些組件，dubbo是應(yīng)用層的組件， 基于dubbo實現(xiàn)的服務(wù)，要訪問數(shù)據(jù)庫，也是跨機房
A1：一般機房之間是光纖直通，但畢竟是跨機房的，延遲和穩(wěn)定性和同機房的不能比。 zk盡量避免跨機房。 我們只用MQ和LoadBalance來跨機房。
Q: 問一下，mysql 同步數(shù)據(jù)到elasticsearch， 你們使用哪個中間件的?
A1：我們同步一般都用mq，數(shù)據(jù)寫入方發(fā)mq，接受方收到消息后更新數(shù)據(jù);不是自動同步， 是業(yè)務(wù)層通過mq異步同步，這樣的話，可以數(shù)據(jù)加工后保存，比較靈活。不需要全量同步
A2: 我們用Eureka，沒有選舉問題;zk一般只做服務(wù)治理，服務(wù)注冊和發(fā)現(xiàn)，我們的集中配罝用的是cloud config 和cloud bus;;Spring Cloud加上cloud bus 能做到在線更新配置后自動同步到所有應(yīng)用
Q2： cloudconfigure和cloudbus有什么區(qū)別?
A2： config只是一個集中配置中心，是靜態(tài)的，Bus是個消息總線，將config的變動及時通給到各個配置消費者
Q2： bus除了分發(fā)配置，還能做消息事件通知嗎?背后的mq中間件有什么要求?是否能高可用
A2： MQ可以是集群啊，BUS就是一個普通的MQ;其實spring cloud的東西挺全的，sleuth可以解決服務(wù)調(diào)用跟蹤，Hystrix可以實現(xiàn)服務(wù)容錯，包括熔斷、線程隔離、服務(wù)降級、請求緩存、請求合并等。
Hystrix 的官方配圖
A3：zk只要在主機房配置為leader和follower,在其他機房配置為觀察者模式就能解決跨機房問題，包括性能和選舉問題
A4：我們現(xiàn)在用的是disconf，搭建起來相對麻煩，但是用起來還蠻好的
3.4 提現(xiàn)T+1到賬的賬務(wù)處理
Q：請教一個問題，我們現(xiàn)在有一個業(yè)務(wù)場景，客戶T日提現(xiàn)，T+1才到賬。這種賬務(wù)上應(yīng)該怎么處理呢?目前有兩種方案：(1)T日凍結(jié)，T+1日做解凍+扣款;(2)T日扣客戶的賬，掛一個應(yīng)付科目，T+1統(tǒng)一從掛賬科目出金。 一般采用哪種方案呢?如果是方案2的話，T+1日出金的時候，是從掛賬科目出，性能和資金安全方面，感覺少了一些保障呢;另外，如果出現(xiàn)付款失敗和退票，也都是先退到過渡戶，再退回到客戶賬戶嗎?
A1：第二種
A2：通常會有個待結(jié)算賬戶，對客戶可見，T+1日做一筆轉(zhuǎn)賬至余額賬戶，也就是每個客戶再另外開一個待結(jié)算賬戶
A3：這兩方案本質(zhì)上沒啥區(qū)別，一個是分開記，一個是合計記，方案2比較明確，退款是由交易發(fā)起的，直接由過渡賬轉(zhuǎn)回;商戶比較特殊，有自己的分戶賬，就簡單多了;如果是用戶的話就沒有必要了，商戶一般不存在打款失敗的情況，只有在成功的情況下進行核銷
Q3: 用戶如果經(jīng)過實名認(rèn)證，應(yīng)該也不會出現(xiàn)打款失敗的情況嘛?
A3: 會的，比如打款通道的問題;我以前遇到過招行天津分行全都失敗的問題，其它的都成功了
Q3: 如果是打款通道的問題導(dǎo)致的付款失敗，退回到客戶賬戶上，也不合適吧?
A3: 這個要看你們的處理流程了，也可以補打啊
Q3: 我們現(xiàn)在基本上是區(qū)分兩種，如果是非客戶賬戶的原因?qū)е碌氖。际茄a打款的，如果是客戶的賬號有問題導(dǎo)致的失敗，就是退回客戶的賬上，等客戶再發(fā)起提現(xiàn)。
A3: 這個流程沒有問題啊，賬號有問題補打也沒有意義 ;但是退款環(huán)節(jié)最好加上審核機制
A4：開戶的時候 會給商戶開4個賬戶
A5：比較支持第2種方式，這里面還有運營方面的需求，查詢?nèi)我鈺r刻待提現(xiàn)的總資金
Q5: 即掛賬科目有可能需要實時統(tǒng)計余額嗎?
A5: 是的
Q5: 這里比較麻煩的就是，掛賬科目，在我們這里屬于內(nèi)部賬戶，不會實時統(tǒng)計余額。請問你們的系統(tǒng)是怎么處理的呢?
A5: 內(nèi)部賬就不能實時了?沒有這個規(guī)定
Q: 內(nèi)部賬戶，一般并發(fā)量比較高，如果實時更新余額，不會有性能問題嗎?我們一般是間隔一段時間統(tǒng)計一次，內(nèi)部賬戶，一般訪問頻率會比較高吧?
A:上次中金的朋友講過了， 我覺得講的挺好的，與業(yè)務(wù)相關(guān)的可以放在賬務(wù)去做，而不用關(guān)心內(nèi)外之分
Q: 出賬的不更新賬戶余額危險很大吧?
A1: 即使你現(xiàn)在內(nèi)部賬戶放在了會計系統(tǒng)也沒有問題，實時或批量都沒問題，沒有人規(guī)定會計系統(tǒng)不能有實時接口。但像打款這樣的賬戶，應(yīng)該是相對穩(wěn)定的，不應(yīng)該是實時更新的
A2: 肯定能實時出余額是最好的，但比較想知道像內(nèi)部賬戶這種并發(fā)量這么大的賬戶，怎么做到實時出余額。剛才的截圖是從一個支付寶比較老的文檔中看到的，不知道還有沒有其他做法。
Q: 實時余額會有問題，余額總在滾動，你如何操作?
A1: 看有沒有哪個大牛，專門說一下這塊吧 這個類似的問題好像群里說了好幾次了 我每次看好像都不太一樣，不知道有沒有統(tǒng)一的一個標(biāo)準(zhǔn)
A2: 所謂緩沖記賬，就是批量上賬
A3: 之前提出好多個無差異的賬戶作為平臺賬戶，我覺得是個不錯的主意哈，對熱點賬戶效果應(yīng)該明顯
A4: 場景不一樣，方案上稍有差別，實時記賬沒有問題，問題是這樣做是不是適合作業(yè)需求。熱點賬戶不打款，這就是差別。
Q: 但是這里的場景不就是要打款么?
A1: 對啊，所以不能用常規(guī)的那種熱點方式，熱點賬戶的解決方案一般是內(nèi)存緩存，定時更新到庫中;對于內(nèi)部賬戶的上賬，批量上就可以;我的建議是先把打款作業(yè)需求梳理清，打款的依據(jù)是打款明細(xì)，而不是賬戶
A2: 關(guān)于熱點賬戶的入賬問題，我的理解是兩種解決方式，一是匯總?cè)胭~，還有就是剛才大家所說的緩沖記賬;兩種方式各有優(yōu)劣，而且在實際業(yè)務(wù)運營中，后者除在并發(fā)波峰外，基本可以做到實時或準(zhǔn)實時
A3: 出款、入賬區(qū)別對待，為確保資金安全，一般是確保賬戶余額減成功后才發(fā)起出款，這里的余額修改通常做實時;入賬如樓上所說，匯總or緩沖
A4: 銀行采用的都是批量，熱點賬戶一般用在某段時間內(nèi)對該賬戶進行頻繁的同時上賬和下賬，因為你不及時上賬，下賬就會出現(xiàn)余額不足
3.5 銀行與三方支付簽約是否要求排他
Q：負(fù)責(zé)聚合支付業(yè)務(wù)的產(chǎn)品或業(yè)務(wù)童鞋，請教一下，現(xiàn)在銀行與支付寶、微信支付，簽訂服務(wù)商或代理商協(xié)議有排他性約束嗎?或者說銀行作為二清類服務(wù)商，能同時與支付寶、微信支付簽訂合作協(xié)議嗎?聽到有人說，現(xiàn)在他倆要求服務(wù)商排他，只能找一家站隊;但實際情況是比較多的銀行同時和多家第三方合作，推出聚合支付服務(wù)，所以想確認(rèn)下~
A1：沒有
A2：可以
A3：沒有，我們有很多銀行客戶都申請了微信和支付寶的銀行機構(gòu)服務(wù)商
Q3: 除了民生、中信外，具體還有哪些銀行呢?
A3: 好多城商行都在干聚合支付了：興業(yè)。浦發(fā)，以及等等
A4：第三方接第三方，需要通過銀行整個擋板賬戶。
Q4: 什么叫第三方接第三方啊? 不是有第三方做第三方的簽約商戶么;易寶好像就代理了微信吧，可以用易寶走微信支付?
A41：通過銀行間連;現(xiàn)在其他第三方通過銀行間連，提供支付寶、微信支付收單服務(wù)的，資金流是消費者賬戶先流向支付寶備付金賬戶，支付寶清算至銀行內(nèi)部賬戶后，銀行二清給商戶，中間不能再經(jīng)過其他第三方的賬戶了;巨頭是這樣要求的;也就是說，此時的第三方的角色定位，就是聚合支付服務(wù)商，收單外包機構(gòu)，和Ping++、收錢吧等角色一樣
A42：所有支付公司做微信支付的，中間都有個第三方
A5：第三方不允許接第三方
Q5：一直有個問題請教一下，關(guān)于三方不允許直接連三方，是在哪個文里規(guī)定的?
A5：2號令
Q5： 2號令我看過，沒有解讀到具體的條款
A5：第一章第四條
Q5：針對這條我一直有個疑惑，假設(shè)易寶代理微信做收單，日終清算時，微信直接將財付通銀行備付金賬戶的資金劃轉(zhuǎn)到易寶的銀行備付金賬戶，應(yīng)該沒有違反第四條規(guī)定吧?
A51：首先財付通是啥?其次，如果財付通是支付機構(gòu)且易寶也是支付機構(gòu)，那么就違反第四條了;樓上A4的同學(xué)對于第三方的解釋有誤，這里的第三方必須擁有清算資質(zhì)，收錢吧之類沒這個
A52：四方不能落賬戶，三方才可以
A53：五方模式?jīng)]意義，支付鏈條太長;五方真的沒有意義，備付金集中存管后，其他第三方再沉淀資金的動力不足了
Q6：接上面，如下圖，易寶代理微信收單，資金清算時，微信直接將其銀行備付金賬戶的資金劃轉(zhuǎn)到易寶的銀行備付金賬戶，再由易寶清算給最終商戶，重點就是中間微信將資金直接劃轉(zhuǎn)到易寶備付金戶這個操作，是否違反2號文?
A61： 易寶微信中間加一個銀行，中間加一個銀行，就需要銀行開內(nèi)部戶過一道資金
A62： 你為啥老要跟備付金扯在一起
A63： 都說了，所有使用微信的支付機構(gòu)都需要有個第三方，誰告訴你直接劃的;銀行是清結(jié)算機構(gòu)，開毛個內(nèi)部戶;銀行的角色就是微信的代理商，只不過有清算能力;說的更直白些，銀行是微信大商戶，易寶是銀行的大商戶，你是易寶的大商戶
A64： 目前一般是這樣的，微信不能直接跟支付機構(gòu)對接的。微信跟支付機構(gòu)只能通過銀行或者結(jié)算中心進行轉(zhuǎn)接。不管是交易還是資金流，都是這樣的
A65： 違反
Q7： 支付公司現(xiàn)在的資金賬戶就是在銀行開的備付金賬戶，支付公司之間要做資金清算，最終結(jié)果就是兩個支付公司之間備付金的資金流動，我現(xiàn)在的問題是，在銀行賬戶層面這個資金通過哪些手段流動過去
A71：個人感覺其實銀行本質(zhì)上不是一個支付機構(gòu)間的清算角色，更像是微信委托銀行做一個代付給易寶
A72：理解下，你是指支付機構(gòu)間的備付金資金轉(zhuǎn)移，好像沒有違反二號令;資金還是通過銀行進行轉(zhuǎn)接清算，而不是支付機構(gòu)見互相開立賬戶直接結(jié)算，這一塊的理解各異，而且現(xiàn)狀是大家都往另一方面理解，so 不用糾結(jié)了
A73：其實第三支付機構(gòu)是不能“銀行化”的。只做好自己的結(jié)算業(yè)務(wù)即可。
Q8：如果聚合提供商平臺接了商戶，資金過第三方支付后，用銀行內(nèi)部賬戶清分給商戶，有問題嗎?
A8：沒有，剛才有童鞋說的很直白，銀行是微信的大商戶，這個大商戶有支付和清算資質(zhì)，再清算給它下面的小商戶，以前微信把這種服務(wù)商，叫做二清類服務(wù)商
Q9：這時候銀行的賬戶體系要建的很全面才行，不然支持不了商戶需求吧?
A9：這個要看合同吧，如果第三方只與銀行簽，那第三方就是銀行的商戶，錢由銀行結(jié)算給第三方，沒有微信什么事
Q10：如果第三方與微信簽的合同，那么銀行就只是個代理，資金理應(yīng)由微信結(jié)，不過目前來看，大部分都是第一種模式。
A10：如果是銀行模式的，就是微信結(jié)算給銀行，銀行結(jié)算給大商戶;如果是直聯(lián)模式和微信簽合同的，就是微信直接結(jié)算給商戶
A101：如果是普通服務(wù)商模式接入的子商戶 子商戶也是和微信簽合同，資料是服務(wù)商錄入，微信是直接結(jié)算給子商戶;而有支付牌照的公司，是不能直接合作的，所以都是通過銀行模式
Q11：銀行模式，銀行根據(jù)什么信息把資金結(jié)算給商戶呢?
A11: 銀行模式下，交易要走銀行系統(tǒng)
Q12：請教下，目前貴司對服務(wù)商有排他性(排支付寶)的約束嗎
A12：沒有排他性，根據(jù)交易對賬單結(jié)算;微信有商戶平臺和對賬，銀行也有自己的商戶平臺和對賬
3.6 代付與二清
Q1：支付機構(gòu)可以為商戶提供代付服務(wù)嗎?
A1：可以
Q2：商戶交易的資金，按道理應(yīng)該進到商戶的結(jié)算賬戶，如果商戶要求，這部分資金，不清算給他，而是根據(jù)他發(fā)的代付指令，代付到其他多個銀行賬號，這是允許的嗎(算不算變相的二清)?
A21：代付資金和清算資金要分開的
A22：你這說的模式，就是代收代付啊，代收代付，繞不開涉嫌二清的嫌疑
A23：有些支付機構(gòu)的支付產(chǎn)品，支持交易實時分潤，但一般代收付平臺喜歡留存資金，不知道算還是不算，這個問題，曾經(jīng)被困擾了很久，因為官方?jīng)]有界定清楚，而且行業(yè)內(nèi)理解也有頗多差異;前段時間，央行對于小額支付系統(tǒng)的集中代收付業(yè)務(wù)，有點一竿子打死的意味，代收確實需要整治下，但代付業(yè)務(wù)是池魚之禍
A24：你這個問題得分情況看：如果是商戶自有資金，只做代發(fā)的話肯定是沒問題的;如果是收單資金，直接資金不過商戶賬戶，直接由銀行或者三方請給最終小商戶，在資金層面也沒有問題，不過也可能存在清算信息層面有擦邊球嫌疑
Q3：是不是這樣理解?商戶不能拿自己的備付金，作代付。但可以另外打款給支付機構(gòu)，作代付?
A3：不是你說的這個意思，我理解你說的應(yīng)該是二級商戶收單清算的場景，你這個場景肯定需要避免二清，底線是資金不過你的賬戶，目前我們有一種模式，銀行開一個內(nèi)部賬戶，支付公司把資金清算到這個內(nèi)部賬戶中，然后銀行根據(jù)你的指令將資金直接清算給最終小商戶
Q4：是不是有點類似二類賬戶的用法?我之前看過二類賬戶的一些用法，看到可以應(yīng)用在代付業(yè)務(wù)上。估計就是你說的這種模式。為大商戶開一個二類賬戶，資金清算到二類賬戶，再發(fā)代付指令給銀行，由銀行從這個賬戶中做代付出去?
A41：你就認(rèn)為是銀行賬戶就行
A42：自有資金，代付業(yè)務(wù)不需要啥牌照資質(zhì)，只要符合代付業(yè)務(wù)準(zhǔn)入即可
Q5：一般支付機構(gòu)發(fā)代付指令，都是需要從備付金賬戶出金的吧?商戶的自有資金，進入到支付機構(gòu)的備付金賬戶上，沒有問題嗎?之前看到快錢是有為商戶提供付款功能的，但不知道具體的業(yè)務(wù)模式是怎么樣的。
A51：感覺沒那么復(fù)雜吧，商戶自己的錢自己愛怎么弄就怎么弄，二清也不是這么防的吧?第三方把錢結(jié)算到商戶賬戶上，商戶再充值到第三方平臺，再代發(fā)，你怎么界定他就是二清?
A52：不同的代付通道，是有區(qū)別的：有的是需要預(yù)充到支付機構(gòu)的備付金賬戶再出金;有的直接可以從企業(yè)的對公戶中劃扣資金
A53：我對二清的理解是接入風(fēng)險，不是業(yè)務(wù)風(fēng)險;商戶的結(jié)算款，只要有協(xié)議，可以轉(zhuǎn)到余額賬戶，余額賬戶當(dāng)然可以代發(fā)了;不論是結(jié)算款轉(zhuǎn)余額代發(fā)，還是自有資金充值代發(fā)，對于第三方公司來說都是一樣的，都屬于負(fù)債類的，對于客戶的負(fù)債清償，肯定是走備付金。
A54：這個結(jié)算資金，不一定全部是該商戶的;商戶做了代收代付業(yè)務(wù)，這里就有涉嫌二清的嫌疑
Q6：總結(jié)起來，按我剛才說的業(yè)務(wù)場景：如果是商戶的結(jié)算款，要做代付：一種就是跟銀行合作，先清算到商戶的結(jié)算賬號，再從商戶的結(jié)算賬號上做代付。一種就是跟商戶簽個協(xié)議，打打擦邊球。如果商戶只是單純的代付業(yè)務(wù)，商戶肯定是要通過不同的方式，將資金劃轉(zhuǎn)到支付機構(gòu)的備付金賬號上，再通過支付機發(fā)代付指令。
A61：合同上寫的是商戶的，結(jié)算資金就是商戶的;是不是二清，關(guān)鍵是看商戶是否開展了二清類的業(yè)務(wù)，不是看他的代發(fā);不用劃轉(zhuǎn)，結(jié)算款本身就在備付金賬戶上，只不過賬務(wù)上要求，這個是進賬
A62：感覺普通商戶的結(jié)算款，基本沒有什么代付的需求吧。
A63：做代收代付類服務(wù)的，一般是平臺型商戶，自身不是商品或服務(wù)的提供方，作為流量入口撮合交易;這個人行一查，還是挺明顯的，也不容易解釋過去。沒有這樣的業(yè)務(wù)場景
A64：不出現(xiàn)資金跑路風(fēng)險，不做大資金池，不沖擊維穩(wěn)剛需，監(jiān)管也是有成本的，類似業(yè)務(wù)事實上大量存在
A65：純代付就是你說的這種模式，商戶直接把資金打到支付公司，然后給支付公司發(fā)代付指令，這是標(biāo)準(zhǔn)代付流程，沒什么問題
A66：對商戶而言;銀行也有代付服務(wù)，不一定要走支付機構(gòu)，支付機構(gòu)的代付通道，溯源也是銀行開放的;而且部分銀行的代付，不需要商戶的對公戶一定是該行，跨行扣款也可行
A67：這需要銀行有代扣通道
3.7 聚合掃碼支付市場行情
Q：有個話題想跟群里的專家們探討一下：目前很多銀行都在做或者開始要做聚合掃碼支付，大部分都會將系統(tǒng)和運營外包，然后也會找些地推服務(wù)商，這塊目前市場行情怎么樣?
A1：關(guān)鍵要確定行方的訴求，長尾市場上的小微商戶，支付寶、微信都不直接地推，銀行直接擼袖子上，成本優(yōu)勢更差;【XX銀行】將在X月底投產(chǎn)統(tǒng)一支付平臺，把行內(nèi)渠道接口標(biāo)準(zhǔn)化，后臺先上二代支付和XX省金服通道。平臺優(yōu)點:統(tǒng)一行內(nèi)接口，統(tǒng)一對賬，統(tǒng)一差錯處理，支持智慧路由和指定路由。做這個平臺主要為了后續(xù)快速接入其它支付通道。1. 超級網(wǎng)銀X月底同構(gòu)到統(tǒng)一支付平臺里; 2. 銀聯(lián)代付X月版投產(chǎn);3. 網(wǎng)聯(lián)X月投產(chǎn);4. 年底再收CISP(跨境人民幣支付系統(tǒng));5. 明年再做:銀聯(lián)代收，SWIFT，還有各個同城~還在搞銀聯(lián)快捷支付需求~。現(xiàn)在存量業(yè)務(wù)與新系統(tǒng)多條線并行，每接一個支付通道，都把行內(nèi)渠道業(yè)務(wù)系統(tǒng)也接過來。例如: X月底超網(wǎng)同構(gòu)和V1.X需求投產(chǎn)，會把現(xiàn)在走超級網(wǎng)銀的:個人網(wǎng)銀，企業(yè)網(wǎng)銀，現(xiàn)金管理，wap手機銀行，微信銀行等等十幾二十個業(yè)務(wù)渠道都接過來
Q：我們現(xiàn)在暫時先不打算把網(wǎng)銀柜臺之類存量業(yè)務(wù)遷過來，只做增加線上支付收單類業(yè)務(wù)
A: 是的，行內(nèi)歷史遺留的支付系統(tǒng)分散，維護團隊不同，開發(fā)平臺和開發(fā)語言不同，造成運維成本高的問題，要徹底解決
Q：你們是用的外包還是行內(nèi)自主開發(fā)?
A：收舊系統(tǒng)要很大成本~很多行都不敢這么玩。行內(nèi)+外包。行內(nèi)主要做:需求分析和方案設(shè)計，接口設(shè)計，數(shù)據(jù)庫設(shè)計，具體到代碼和測試那塊由外包做。
【本文為51CTO專欄作者“鳳凰牌老熊”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號“鳳凰牌老熊”聯(lián)系作者本人】
