一、目前对账的算法：

1、从上游渠道（银行、银联等金融机构）获取对账文件，程序逐行解析入库

2、在存储过程中，以上游对账文件的表为基准，程序逐行读取并与我们系统的交易记录/账务记录（有账务系统情况下，合理方案应该是于账务记录）对比，查找出差异记录。

3、以我们系统的交易记录/账务记录为基准，程序逐行读取与上游对账文件对比，查找出差异记录

二、目前对账算法问题：

1、使用存储过程，对账过程都在数据库端完成，对数据库性能影响较大，而且对账逻辑扩展极为麻烦

2、逐行比对算法效率较低，但算法上并无好的优化余地。如果采用数据库INTERSECT、MINUS对数据库压力也高。

3、在业务量大的情况下（例如有上百家上游渠道需要对，每一家都有几十万条交易记录），对账服务器及数据库服务器负荷较高。即便采用读写分离，对账时候使用读库，压力一样很大。

4、导入批量文件，逐行入库效率较为低下（每一次都需要建立网络连接、关闭连接）

三、对账算法优化思路：

1、涉及网络传输的，尽量采用批量方式操作，减少网络消耗及时间消耗

2、使用Redis等NOSQL数据库，降低数据库服务器的压力。同时在扩展上也容易，一台Redis服务器不够，可以无限制增加用于对账用的服务器。

3、使用Redis的set集合的sdiff功能，利用Redis sdiff算法的高性能，比对上游记录和我方记录的差异

四、对账算法说明：

1、利用Oracle/Mysql的load data infile将对账文件批量导入到数据库

2、程序读取上游账务记录表，对上游账户记录执行select  concat(channel_id, ":" , order_id , ":" , HASH_MD5(channel_id , order_id , amount , status , timestamp1 , timestamp2 ,…) )  as hashid from table ，得到对应的SET集合。

这里思路是将需要对账的记录拼成格式为：channel_id:order_id:hashid形式的串，以便作为Redis SET集合的item。

其中channel_id和order_id用于标识对应的渠道及订单，只是例子，根据实际需要补充。之所以要在hashid前面带上channel_id和order_id，主要目的是在sdiff后，能够作为主键，根据set结合的item查找出对应的数据库记录。

3、对我方的交易记录表/账户历史表采用上一步的类似算法，得到对应的SET结合

4、采用Redis的pipeline功能（Redis的各种客户端，包括java客户端jedis 都提供此功能），将上游账务记录SET集合和我方的交易记录/账务历史记录SET集分别批量执行sadd插入Redis，得到两个SET集合。

由于单条记录sadd 插入Redis效率较差（每一次都涉及网络open、close、传输消耗），因此使用Redis的pipeline功能，已实现批量入库功能。

可以参考：http://redis.io/topics/mass-insert

5、利用redis的sdiff功能查找出上游账务集合与我方记录集合的差值

6、从sdiff 集合中channel_id:order_id:hash，定位对应的数据库记录，更新对账状态。

具体性能及实现可以在实现后测试对比一下，应该会有大幅的性能提升。

我在知乎就问题《POS签购单上的授权号，凭证号，参考号，批次号，分别是什么？有什么作用》做的回答。

下面定义及术语参考了《中国银联POS终端规范》及《中国银联银行卡联网联合技术规范V2.1 第2部分 报文接口规范》两个规范。
批次号(Batch NO.)：POS从签到起至结算、签退为止的交易为一批次，交易批次号标识一批交易。POS中心为每个POS的每个批次分配一个批次号，在签到响应报文中下传给POS终端。
对应银联ISO8583报文的报文头域7： 批次号(Batch Number)

序号(Ref. NO.)：POS中心为交易分配的流水号，在响应报文中下传给POS终端作为对账参考号，并用于事后查证。
对应银联ISO8583报文的域37：检索参考号（Retrieval Reference Number）

授权号(Auth Code)：授权标识应答码，简称“授权码”。是发卡行返回或银联CUPS代授权时返回的授权序号。
对应银联ISO8583报文的域38：授权标识应答码 Authorization Identification Response

查询号(Trace NO.)：POS机为每一笔交易产生的顺序编号。POS每上送一次交易此号码增加1。 POS流水号为6位数字，值从1至999999循环使用。在自动冲正时，POS中心依据POS流水号作为确定被冲正交易的要素之一。
交易发起方赋予交易的一组数字,与域7（交易传输时间 Transmission Date/Time）、域32（受理机构标识码 Acquiring Institution Identification Code）和域33（发送机构标识码 Forwarding Institution Identification Code）的组合值唯一标识一笔交易的编号。

凭证号(Voucher NO.)：查询号(Trace NO. 也叫POS流水号)也作为交易凭证号（在签购单上打印为Voucher NO.），在进行撤销等交易时，输入原交易凭证号作为确定原交易的要素之一，并且必须上送原交易的凭证号。

要确认一笔交易，分为发卡行和收单方：
对发卡行来说：卡号+参考号+授权号，就能够确定一笔交易
对于收单方来说：凭证号+域7（对应签购单上的日期/时间）+域32（对应签购单上的收单机构）+33域（对应签购单上的发卡机构）能够唯一确定一笔交易
因此如果是向发卡行投诉，则需要提供卡号、参考号、授权号。
如果是向收单方投诉，则需要提供凭证号、交易日期时间、收单机构、发卡机构

知乎回答原文链接：http://www.zhihu.com/question/29519161/answer/45062087

我在知乎就问题《如何开发一个好的普惠金融产品?》做的回答。

这话题太庞大，只能尝试从自己角度回答一下。
1、互联网金融产品从产品属性属性来说分为两种：金融端产品、互联网端产品
其中金融端产品主要指传统金融提供的各种金融产品。究其原因在于目前金融监管限制，互联网金融还很难有真正意义上的金融端产品创新。
互联网端产品主要指依托互联网渠道的各种产品、服务等。

2、互联网金融产品产品度量指标：
金融端产品的度量指标：风险、收益、流动性
互联网端产品的度量指标：创新、用户体验、用户口碑、用户数/流量

3、互联网金融产品玩法：
a、金融产品端的玩法：
监管套利、信息不对称、资源重配置等。
对现有传统金融产品通过组合、移植、包装等方式，形成互联网金融的金融端产品。
b、互联网产品端的玩法：
去中介化/脱媒、口碑传播、流量及长尾效应、持续运营

4、普惠金融产品开发挑战：
a、团队磨合
由于涉及金融产品团队、互联网产品团队等不同角色，不同团队的文化氛围、管理模式、风格、关注点等都不尽相同，怎样让团队尽快磨合，协同作战。
b、口碑及信任感建立
互联网金融的价值之一在于可以利用互联网渠道的口碑传播，快速放大产品及公司品牌影响力，但由于互联网金融产品的金融属性，用户对平台的信任感是平台的核心竞争力。怎样让产品获得良好口碑，培育用户起对平台信任感成为优秀产品的核心任务。

5、产品开发模式
精益创业的MVP方法、Scrum等。

6、怎样开发一个好的互联网金融产品
1）、跨职能的项目团队搭建
2）、市场调研，定位目标用户群
3）、金融产品设计及定价
4）、互联网产品设计
5）、互联网产品开发
6）、种子期用户试点
由于互联网产品的研发有一个过程，如果业务模式允许，在系统未上线前可并行采用手工方式进行金融产品试点验证（MVP方法）。
7）、运营数据分析及产品策略分析
8）、产品完善（包括定价策略、营销策略、IT系统等）
9）、扩大试点范围（受众群、区域、渠道等）
10）、运营数据分析->产品完善->更大规模推广及运营

7、好的互联网金融产品评价标准
可以参考 互联网金融运营需要关注的数据有哪些呢？ – 梁川的回答

知乎回答原文链接：http://www.zhihu.com/question/29358993/answer/44781757

我在知乎就问题《如何搭建二维码支付系统?》做的回答。

1、如果是在线交易，要支持扫码支付，只需要在将原有交易过程的支付链接及信息生成对应的二维码即可。
2、如果是线下交易，要支持二维码支付，主要问题在于考虑怎样让传统线下收银机、POS机支持扫码支付。
目前业内的主流做法：
a、铺设定制终端设备，串接在收银机、打印机之间，抓取收银机、打印机之间的通信协议，将传统的小票信息改造成支持二维码的小票。消费者使用银行/商户/第三方支付的APP对着打印出来的小票扫码完成支付。
b、铺设支持二维码的POS机或收银机，例如微信POS机。消费者对着POS或收银机或打印出的小票扫码完成支付。
1、2中，在支付环节，与传统在线支付/移动支付并无太大差异。
在安全上，与传统在线支付的商户收款链接的安全处理类似，最核心的问题是：怎样保证支付链接地址不是钓鱼地址。

知乎回答原文链接地址：http://www.zhihu.com/question/29325751/answer/43978310

我在知乎就问题《美团、饿了么这些平台先收消费者的钱，然后再转账给商户，在财务上是怎么处理的？》做的回答。

本质上是美团、饿了这样的平台对合作商户结算及结算资金转移问题。
为简单起见，未单独说明的，以下所指的“平台”指美团、饿了这样的平台。
1、平台自己接银行
如果平台与银行有较深的合作关系（例如与银行联合做营销活动，银行有营销费用补贴等优惠），或者第三方支付的支付接口满足不了业务需要时候，平台可以直接银行，提供在线支付、银企直连等功能。
账户设置上，平台在银行开设自己的银行账户。
平台与银行的对账、结算：平台按照结算周期与银行对账后，银行将结算周期内的资金结算到平台在银行设立的账户上。此处由于是同行交易，因此不存在费用。
平台与商户的对账、结算：平台按照与商户约定的结算周期进行对账、结算（如果存在类似联盟、分销的情况，可能还包括分账），此时只是在平台自己的交易、账务系统中做处理，并未完成资金实际的转移。一般情况下，由于平台具有话语权，而且考虑到手续费问题，平台与商户不一定按照结算周期就结算的，可能会在交易额达到一定额度时候再一次性结算。
平台将结算资金实际转移给商户时候，存在几种途径：
a、平台的财务人员通过企业网银同行/跨行转账
b、平台调用银行的银企直连之类的接口完成同行/跨行转账
c、通过其他平台的代付功能（也有叫委托结算）完成代付。
具体收费上，只能具体情况谈。
2、平台接第三方支付
第一种方式由于涉及与银行接口联调以及还需要平台自己处理对商户的清结算、分账、代付等问题，这些并不是平台所擅长的，而且在整体费用上并不具备优势（例如涉及一堆小银行跨行转账），因此平台会同时接入多家第三方支付，借助第三方支付相对专业化服务来帮助解决这块。
账户设置上，第三方支付会按照商户接入流程要求平台提供银行结算账户、营业执照等信息，然后在运营系统中开通平台对应的虚拟账户。
每一笔成功交易产生后，都会汇总到平台在第三方支付的虚拟账户中。
在银行端，按照央行备付金管理办法，第三方支付会有收付户、汇缴户等类型的账户，用于存放所有合作商户的备付金，但并不区分某一个商户的资金。从资金安全角度来说，备付金管理办法就是为了监管第三方支付对商户资金挪用、洗钱等风险。
第三方支付平台按照结算周期与平台对账、结算，对账结算完成后，第三方支付平台一般提供了诸如代付/委托结算、分账功能，能够将资金代付给商户。另外还提供了诸如对公/对私结算、周末及节假日委托结算、T+0结算、商户自助上传批量代付文件、银行回单等增值服务。
在具体费用上，正如前面提到的，如果平台合作商户的结算银行比较分散，则在整体成本上，应该比平台自己接银行具有优势。

知乎回答原文链接：http://www.zhihu.com/question/29276036/answer/43865460

我在知乎就问题《如何从零起步学习支付行业相关知识？》做的回答。

既然提的是产品经理，需要明确强调的一点：
虽然同为互联网产品经理，作为支付产品经理与其他偏内容、体验导向的互联网产品经理（例如微博、门户、SNS等）在技能有很多不同。
最大的差异在于：支付产品经理需要较强的逻辑思维能力，并对后端系统技术实现有一定的理解。主要原因在于支付系统最为麻烦不在于前端的用户体验，而是后端复杂业务逻辑。如果不理解已有系统的需求场景、实现逻辑、局限性、约束，那最终产品经理只能沦落为需求的传声筒。这也是为何诸多支付公司的技术同学们总觉得产品经理可有可无（虽然偏妥，但也不无道理）。
因此，要入门支付行业做产品，如果不希望变为只是空谈用户体验“传声筒式”的产品经理，首先一定要努力提升自己的逻辑思维能力、技术能力，这也是为何在支付行业摸爬滚打多年的都有类似观点：好的支付产品经理应当有技术背景。
由于支付行业涉及金融、电子商务、所处行业知识、互联网产品管理等等方面的知识，不可能三言两语就说清楚需要学习那些知识，这里从怎样入门提一些参考建议。
1、先作为用户及商户体验了解第三方支付平台在整个交易过程中的角色及作用
商户涉及签约、系统接入、交易及异常处理（例如掉单、重复订单）、运营对账及清结算等方面。
用户涉及从商家平台（例如电商、游戏）购物、生成订单、支付等过程。
商户角色可以看看第三方支付所提供的接入SDK。
用户可以直接找个电商平台、游戏平台实际购买体验一下支付过程。
值得注意的是由于有使用神州行卡、游戏点卡支付的场景，因此游戏行业的商户与电商平台的商户支付流程上并不完全相同，同理POS收单、预付费、移动支付、外卡收单等支付过程也不尽相同。
2、积极参与一个支付产品日常运营问题处理，从问题入手，进而熟悉所负责产品的行业需求、业务逻辑、问题、行业知识
如果是从零开始做支付，强烈建议先做上一段时间的运营人员、客服人员，并建立与客服的沟通机制。在此过程中熟悉所负责产品的主要问题，从运营问题入手，边干边学。这样目标更明确。
3、在日常产品设计中，对自己高标准要求，不要以传声筒或撒手掌柜的标准来要求自己。在产品方案中，强迫自己写清楚产品业务用例的实现逻辑，全程参与技术实现细节的讨论中（注意是参与不是主导），不耻下问，向技术了解系统实现逻辑。
4、多多使用竞争对手的产品及行业解决方案，扩大知识面及视野
支付方面的图书较少，可以在当当、亚马逊搜索一下，就不做推荐了。
提供一本电子书《第三方电子支付探索与实践》，供参考 第三方电子支付探索与实践，完整扫描版.pdf_免费高速下载 。
利益相关：参与过此书写作，并不是说很好，只是供参考。

知乎回答原文链接：http://www.zhihu.com/question/29217557/answer/43815296

我在知乎就问题《什么样的能量才能支撑一个人走过人生的低谷和迷茫？》做的回答。

自己在2012–2014年之间也经历了从全力以赴创业到创业失败的痛苦经历，能够理解题主当下的孤独、迷茫和内心煎熬。
处在人生的低谷中，持久的激励只能依靠自身内在的觉醒，外部给予的各种正能量只能是短暂的。同时也别太指望通过各种理性分析方法来帮助自己从迷茫中走出来，我们之所以遭遇失败及感到迷茫，很大的原因之一在于：我们处于能力瓶颈期（平台期），我们很难依靠固有的思维模式及理性分析来突破当前的平台。
要突破这个瓶颈，可以通过放空自己的方式来获得。强烈建议通过肉体的锻炼+内心的修炼来帮助自己看清楚人生的意义、自己的价值和需求。
肉体的锻炼推荐快走、跑步。
内心的修炼推荐打坐、禅修。
在 你是如何度过那些孤独又恐惧的日子？ – 梁川的回答 和 哪些书让你读了之后对自己进行了深刻的内省？ – 梁川的回答 做过类似的阐述，供参考，希望有所帮助。

知乎回答原文链接：http://www.zhihu.com/question/29064178/answer/43728359

我在知乎就问题《互联网金融运营需要关注的数据有哪些呢？》做的回答。

由于互联网金融概念较为宽泛，支付、投资理财、信贷、征信、虚拟货币发行（比特币等）、金融产品搜索等不同领域所关注的核心指标并不相同；即便是相同领域的公司，由于核心业务模式的差异导致大家所关注指标也不相同。因此从运营角度来看，最靠谱的是结合公司的核心业务模式来归纳运营指标。

备注：由于互联网金融公司的金融属性，从经营风险的角度来看，风险贯穿互联网金融公司的企业日常运营、IT平台运营等过程，这与普通互联网公司的运营主要关注产品运营有极大不同，因此以下所指的运营并不单纯指普通互联网公司的运营部门的运营，而是从整个互联网公司企业运营角度来说的（其实也是运营人员需要关注的），姑且叫大运营吧。

不妨先看看一家互联网金融公司正常运营要关注的问题（其实也是核心业务模式）：
1、目标用户是谁，目标用户的分级体系？
2、提供什么样金融产品，金融产品的核心价值？例如收益、风险、流动性等
3、通过什么渠道找到目标用户？例如搜索引擎竞价、微信、APP、朋友圈、渠道合作伙伴等等
4、举办什么样的营销活动来扩大影响力，拓展新用户、提升老用户活跃度？
5、合作伙伴是谁？包括担保公司、保理、信托、银行、渠道合作等
6、怎样进行风险控制？包括政策法规风险、项目风险、系统风险、操作风险等
7、用户通过什么渠道投融资（支付）？第三方支付、网银转账、线下汇款、移动支付、POS等等
8、怎样搭建NB的IT支撑平台？用户体验要好、系统要安全可靠稳定等等
9、怎样服务好用户？客服体系、运营体系等等的搭建
10、怎样从众多竞争对手中脱颖而出，建立品牌形象并维系好品牌形象？

针对以上问题，可以总结出对应量化指标体系：
1、用户指标：包括用户信用评级、活跃度、留存率、转化率、客单价（平均投资额度）、用户分布（各等级占比）、互动指标等等。
2、产品指标：产品组合、投资人数、投资金额、满标时间、收益率、流标数、风险系数、热度（受欢迎度）等等。
3、营销渠道指标：渠道来源、渠道转化率、渠道成功率、渠道成本等等
4、营销活动指标：活动成本、活动渠道来源、活动转化率、传播数、新增粉丝数/用户数等等
5、合作方指标：合作带来的项目数、项目通过率、风险系数、成本等等
6、风控指标：项目审核通过率、风险备用金、项目流动性风险指标、合规相关指标等等
7、支付渠道指标：渠道转化率、渠道成功率、支付渠道来源、渠道成本等等
8、IT平台指标：用户体验指标（包括响应速度等）、可靠性指标、安全性指标等等。这块与互联网的指标类似。
9、客服指标：投诉分类、接通率、投诉渠道、响应速度、满意度等等
10、竞争性指标：竞争对手分析指标、互联网舆情监控指标等等

知乎回答原文链接：http://www.zhihu.com/question/29164071/answer/43503400

我在知乎就问题《互联网金融产品如何利用大数据做风控？》做的回答。

由于互联网金融涉及货币发行（比特币）、第三方支付、投资理财（网络银行、保险、基金、证券、财富管理）、信贷（P2P、众筹、网络微贷）、征信等等，各个领域的风控策略并不尽相同，不能一概而论，下面讨论只能涵盖了常见的风控策略。
个人认为“大数据”除了强调数据的海量外，更重要的在于用于风控的历史数据的广度和深度，其中：
数据的广度：指用于风控的数据源多样化，任何互联网金融企业并不能指望依据单一的海量数据就解决风控问题，正如在传统金融风控中强调的“交叉验证”的原则一样，应当通过多样化的数据来交叉验证风险模型。以下的风控策略也如此，可能对同一风险事件采用了多种策略。
数据的深度：指用于风控的数据应当基于某个垂直领域真实业务场景及过程完整记录，从而保证数据能够还原真实的业务过程逻辑。
一个关于数据深度典型的反例：第三方支付貌似有丰富的真实交易记录，但由于大部分场景下无法获取交易商品的详细信息及用户身份，在用于风控时候价值大打折扣。

回到题主的话题：互联网金融产品如何利用大数据做风控。大致有如下一些常见方法：
1、基于某类特定目标人群、特定行业、商圈等做风控
由于针对特定人员、行业、商圈等垂直目标做深耕，较为容易建立对应的风险点及风控策略。
例如：
针对大学生的消费贷，主要针对大学生人群的特征
针对农业机具行业的融资担保。
针对批发市场商圈的信贷。

2、基于自有平台身份数据、历史交易数据、支付数据、信用数据、行为数据、黑名单/白名单等数据做风控
身份数据：实名认证信息（姓名、身份证号、手机号、银行卡、单位、职位）、行业、家庭住址、单位地址、关系圈等等。
交易数据/支付数据：例如B2C/B2B/C2C电商平台的交易数据，P2P平台的借款、投资的交易数据等。
信用数据：例如P2P平台借款、还款等行为累积形成的信用数据，电商平台根据交易行为形成的信用数据及信用分（京东白条、支付宝花呗），SNS平台的信用数据。
行为数据：例如电商的购买行为、互动行为、实名认证行为（例如类似新浪微博单位认证及好友认证）、修改资料（例如修改家庭及单位住址，通过更换频率来确认职业稳定性）。 
黑名单/白名单：信用卡黑名单、账户白名单等。

3、基于第三方平台服务及数据做风控
互联网征信平台（非人行征信）、行业联盟共享数据（例如小贷联盟、P2P联盟） FICO服务
Retail Decisions(ReD)、Maxmind服务
IP地址库、代理服务器、盗卡/伪卡数据库、恶意网址库等
舆情监控及趋势、口碑服务。诸如宏观政策、行业趋势及个体案例的分析等等

4、基于传统行业数据做风控
人行征信、工商、税务、房管、法院、公安、金融机构、车管所、电信、公共事业（水电煤）等传统行业数据。

5、线下实地尽职调查数据
包括自建风控团队做线下尽职调查模式以及与小贷公司、典当、第三方信用管理公司等传统线下企业合作做风控的模式。
虽然貌似与大数据无关，但线下风控数据也是大数据风控的重要数据来源和手段。

知乎原文回答链接：http://www.zhihu.com/question/27715270/answer/43411182