金融业务架构的技术挑战

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 金融行业赚钱的方法有很多,最核心的原理只有:利用信息不对称赚钱。信息有很多不对称方式,用到的系统工具也都不一样。

业务的技术实现要点

金融行业赚钱的方法有很多,最核心的原理只有:利用信息不对称赚钱。


信息有很多不对称方式,用到的系统工具也都不一样。


1 信贷类业务

1.1 传统信贷业务

信贷业务俗称放贷,传统银行主要从事业务。表现形式有面向企业的贷款,房贷,P2P,花呗、借呗、白条等。


信贷类业务利用了哪些信息不对称来挣钱?比如说你的公司需要一大笔临时贷款买原材料,但资金量太大,找不到人借你。但有位有钱人,他有一大笔钱,却一直贷不出去,没有办法增值。


这时候银行作为中介机构。有钱人把手上的钱用低利息存进银行,银行转手把钱用高利息贷款给你。通过将利息低买高卖,银行就能“躺赚”。银行通过信贷业务赚钱的过程:


5.jpeg


贷款可能违约。一旦违约,银行亏的就不仅是利息,还包括所有本金。违约表示银行对还款人的个人或公司信息了解还不全面,也是一种信息不对称。


银行需要解决这个信息不对称问题防止亏欠。毕竟不亏钱就是赚钱。所以传统银行需要通过收集数据评价借款人的还款能力,即借款人的信用评级。银行信用评级过程主要依靠信贷员对借款方的熟悉程度。


所以,这种传统银行信贷业务买卖利息的操作,对信息系统的要求不高。它只要求结果正确,对时间、吞吐量都没要求,信息技术并不是传统信贷业务的核心竞争力。


不过这点因为互联网和大数据的出现而发生改变。有了互联网和大数据,银行能快速全面而且低成本地了解借款方的情况。你平时在电商网站上的各种消费,玩游戏时充的点券,以及出行旅游的地点和酒店级别,都可以描述还款能力。


这时候信贷行业的核心竞争力变成怎么才能更好地收集和处理数据。这就是大数据价值。


对于系统架构来说,信贷业务的特点是交易频率低,而且用户评级在短时间内不会大变,因此整个系统架构不需要实时组件,常用的批处理、大数据处理框架都能很好发挥作用。


当然了,如果你想要提高用户体验,给用户一种实时放款感觉,系统可提前算好用户信用评级。你经常见到的各种信用分就是这个提前计算的结果。


1.1.1 次贷危机后的信贷业务

你的银行定息存折是可以抵押给银行,然后再贷款?这就是资产证券化。


2008年发生的次贷危机就是用个人的房贷来抵押贷款。简单的抵押赚不了啥钱,所以有些聪明人把一大堆房贷打个大包,然后按信用评级拆分成几个小包。类似的小包还可堆在一起,再继续拆分。最后再将拆分好的小包卖给投资人。


奇迹出现了,按数学公式计算,房贷总量虽没变,但分分拆拆后,总价值反而增加很多,金融公司就躺着赚钱。次贷将资产打包拆分的示意图:


4.jpeg


P2P、花呗、借呗和白条等背后都是这种资本运作,只不过它们将资产证券化的资产从房贷换成个人消费贷。那这种资产证券化的金融业务,对信息系统有什么要求?


1.1.2 金融数学原理

贷款可能违约,违约大小通过信用评级衡量。所以违约率是数学概率。把不同资产放在一起,打包后再拆分的过程,从数学看,就是用一组随机变量生成一个新随机变量。


次贷危机原因是区域性的房贷违约,即概率上,房贷违约率间有强相关性。这些相关性让最后生成的新随机变量的计算公式很复杂。这意味着资产证券化的定价过程对系统有挑战:


计算复杂

数学公式可能一页纸写不下,开发怎么正确实现就是难题。就算你觉得自己实现正确,又怎么证明?


数据量大

资产证券化到一定程度后就算不出来数学公式,只能通过暴力求解穷举所有可能场景。这可能是天文数字,需成千上万台机器同时计算才能及时算出来。这就涉及如何保证分布式计算正确性。


2 交易类业务

信贷类业务主要由传统银行完成,对信息技术的应用有限。金融行业也有很多高科技,主要体现在投资银行和其他新兴金融机构。它们多半从事交易类业务。


这是一个非常巨大的隐形的金融市场,一般难了解全貌。


2.1 场内交易

股票交易所金融机构。在交易所内的交易叫场内交易,交易的场所就是交易所。


交易所角度

很多企业家定义自己是否成功,就看能不能上市:这家公司的股票可在股票交易所内交易,就是股票在二级市场交易。一级市场是公司股东之间的私下交易。


一级市场的信息不对称,主要体现在如何匹配大额股票的买家和卖家。投资银行解决信息不对称的方式是通过公司和自己的人脉来撮合买卖双方。由于解决方案是靠人而非靠技术,所以这一阶段对信息系统要求不高。


就算投资银行撮合一级市场的买卖双方,依然还有信息不对称,那就是股票真正价值多少?


公开交易市场能发现合理的价格信息。所以为解决价格信息不对称问题,投资银行会帮客户公司将股票在流动性高的二级市场上销售。由于二级市场是公开市场,靠大量交易来解决价格信息不对称问题,而非靠人脉。这就对信息系统有很高要求。


信息沟通越快,就越能发现资产的合理价格。所以股票交易强调交易速度,即系统延时。对开发人员,股票交易所是个秒杀系统,和电商秒杀区别在于股票交易所每时每刻都在秒杀。所以股票交易所要有一个极低延时、极高吞吐量的系统架构。


交易所技术


分库分表、缓存、最终一致性等互联网方案都是靠牺牲延时来换取流量。对于股票交易所,高延时完全不可接受。软件很难实现微秒级延时,就算达到这延时,系统吞吐量也上不去。但股票交易所确确实实既有低延时又有高吞吐量,怎么做到的?用硬件,如FPGA实现。理论上硬件能实现和所有软件一样功能,但硬件研发成本高,耗时。股票交易所恰好不怕这些问题。交易所别的没有,就钱多,所以只要ROI足够,再多钱都能拿出来。而研发时间久在交易所里问题也不大,主要因为交易所业务逻辑非常简单。


交易所的主要功能是撮合买方、卖方。交易所在系统内维护还没有成交的卖方订单和买方订单。当一个新订单进来,交易所会查看能不能成交。不能成交就等待下一笔订单。撮合逻辑简单:

3.jpeg



交易所用户角度


股票上市后依然存在信息不对称。有些金融机构故意增加信息不对称,另一些金融机构努力发现和消除这些信息不对称。你我是股票小散户,在股市掀不起风浪。但若你掌管一家大型机构,机构里每次买卖都是上亿资金,很可能影响市场价格。而且通常是负面影响,即会让你买得更贵,或卖得更便宜。如何避免?


这时候,投资银行或券商会给你提供一个拆单服务,将你的大订单拆成很多小订单,并选择在不同时间发送到股票交易所,就不会产生剧烈市场波动。即投资银行需要有个算法交易平台。这个平台需要实时对市场数据进行分析,用算法来拆解和执行订单。


拆单服务本质是造成信息不对称。一般用户无法获取你正在大量交易股票的信息。既然投资银行赚钱是通过信息技术造成信息不对称,有没有可能通过消除这些信息不对称来赚钱?


做高频交易的对冲基金,一类通过发现和消除信息不对称来赚钱的金融机构。核心竞争力就是极低系统延时:


延时高,股票体现宏观规律**,比如你会看公司的基本面,或猜是不是庄家在出货**

但当延时低时,股票体现的是统计规律

比如股票拆单,若你发现一个小的买单,那接下来很可能有很多小的买单。如果你系统的延时够低,就可以挤在这些小单前买入,然后马上卖出,从而通过超短线操作获利。所以高频交易系统也有算法交易平台,也需要以极低延时来分析实时市场数据,且以极低延时执行订单。


交易所的机构和用户间互相在玩猫鼠游戏,谁系统速度快,谁就更可能发现赚钱先机。所以交易所相关金融机构对系统要求高,一些极其领先的软硬件技术在这里都能找到身影,这也是为何大型金融机构都说自己是高科技公司。


交易所用户技术


交易所用户都很关心系统延时。那么延时究竟需要有多低呢?一般来说,机构用户要求系统的消息处理时间在毫秒和微秒之间(1/1000~1/1000000秒)。


极低延时的系统架构

编程语言

C首选,核心代码用汇编语言。要求不高的地方C++也可。


软件架构

金融软件和互联网软件架构的最大不同。互联网软件通常SOA或微服务架构。这种架构导致业务的调用链很长,每次调用都有网络延时。


交易所用户架构完全相反。系统用单进程完成所有的事情,最好不要有网络开销。如果交易所允许,金融公司还会出钱将机器放在交易所的机房。进一步缩短光的传输距离,节省宝贵的数据传输时间。


由于种种原因,目前国内的交易所和券商在信息技术这一块还没ms级以下需求。但随金融系统逐步开放,外资金融机构会带着这些成熟技术竞争。


2.2 场外交易

股票市场和其它的场内交易只是金融市场的冰山一角。绝大部分的金融交易都发生在交易所外,也叫场外交易。


金融产品


场外交易的金融产品类型非常广。如果你想私下交易股票,这个行为也属于场外交易。外汇交易虽然和股票市场类似,但是外汇交易没有交易所,也属于场外交易。你平时听过的花呗、借呗、白条、P2P、供应链金融等,一旦它们被资产证券化,也属于场外交易。那这些场外交易产品,它们对于信息系统又有什么要求呢?


合同定价与市场风险计算


交易所的一个功能:发现价格。人们通过在公开市场交易来消除价格信息的不对称。那场外交易没有交易所,怎么发现价格?


既然你在场外交易时,没法被动发现价格,只能主动发现价格。所以对场外交易的金融产品,你需要独立计算出合同价格。


定价系统需处理复杂度和数据量问题,这也是对所有场外交易定价系统的要求。但资产证券化只是一种场外交易的金融产品,不同的产品定价方式完全不一样,时间长了怎么解决定价系统数量多的问题?


所有场外交易的金融产品都存在共性,比如说它们肯定都跟钱有关。这些共性可进一步提炼出来,从而有希望搭建一个金融产品的统一定价平台。这抽象总结的方法就是DDD。


总结

传统银行主要处理放贷业务,在很长一段时间无需信息技术帮助。但信息技术崛起不仅提高用户信用评级的准确度,成本还很低。这时候的信息系统需要具备批处理计算的能力。


2008年次贷危机之后,人们学会了如何复制次贷这种金融模式,衍生出了很多信贷类的资产证券化产品。这些产品要求系统能解决复杂度和数据量的问题。


交易类业务分成场内和场外两种交易模式。


股票交易所是一种常见的场内交易模式。对于股票交易所来说,信息系统需要解决极低延时,极高吞吐量的交易问题。股票交易所的用户对速度和吞吐量也有同样的要求。但是他们彼此之间会互相竞争,需要用算法交易平台来发现彼此的赚钱机会。这对编程语言和架构的选择都带来了很大的影响。


场外交易的金融产品类型众多,因此需要用到DDD降低定价系统的复杂度。


FAQ

上世纪中期美国,银行定义是吸纳存款并发放贷款。一旦一家金融机构被定性成银行,就要接受美联储监管。监管会限制金融机构行为,因此金融机构并不一定愿意成为银行。若你是一家银行CEO,既不想被定性成银行,又想做一些银行事,准备做怎样业务调整?将存款改成金融产品,成立基金,出售理财产品,蚂蚁的玩法。当个中间机构,聚集资金,借贷给有资金需求的人,p2p。


为什么有些虚拟货币的交易所是用Java实现交易系统的?评价一个系统的时候,除了要查看它的业务覆盖完整度以外,还要看它支持质量。金融服务有很多不同的质量级别,有面向普通用户的,有面向专业用户的,有面向机构用户的。一般来说,使用者专业程度越高,对金融服务的要求越高。


虚拟加密货币从诞生到现在也不过十年。这期间所有人都在摸索这个新兴行业应该如何发展。这时候行业还没有总结出标准的问题,没有标准解法,也没有标准实现,也就是说用户和交易所都在成熟的过程中。


ROI,这时你一定有上新业务的速度和提高现有业务质量这两方面的选择。有的人会觉得业务差不多成熟,专业用户已经出现,而且会向头部集中,这时候需要提高质量。有的人会觉得业务还不太确定,需要多试试方向,需要上线速度快。这就决定交易系统的质量应如何。加密货币交易所用什么技术和创始人的背景有很大关系。金融公司出来的人会注重自己的声誉,重视稳定性、延时和安全。互联网出来的,注重业务时效性,用互联网技术偏多。总之,存在不一定合理,但是一定有背后的原因。需要具体问题具体分析。


用存折抵押给银行再贷款容易理解,因为我有存款,那用房贷抵押贷款是不是等于把房子抵押给银行再贷款?房贷抵押贷款有几个细节。首先用户的房贷其实是用户将房子抵押给银行后,银行贷款。银行在贷款后,手上会有一份用户的还款合同。这份还款合同对投资人来说对应未来的现金流,因此是有价证券。所以该有价证券还可出售或抵押,即“用房贷再抵押贷款”。


存折抵押贷款也是类似,只不过存折和房贷方向相反。在房贷下,银行是拥有资产的人,银行可将房贷资产抵押或者出售。在存折的情况下,用户是拥有资产的人,用户可以将存折抵押或出售。


交易类业务有:场内交易、场外交易,但支付也属于交易类业务,它又好像和场内交易、场外交易不沾边,那支付又该划分到哪儿呢?它又有什么特点?C端金融即支付。第三节课讲的是B端金融,所以有场外和场内的分类。所以支付是不能够按照内外来划分的。


贷款资产包卖给投资机构,投资机构和银行一样也是赚还款利息吗?


资产包这时等同于一个债券。用户相当于债券发行方,需要付利息。投资机构或银行用某个价格购买债券,之后获得利息收入。机构也可以在价格合适的时候将资产再卖出,也能获利。


其实在国外有时候也会把这种复杂的金融业务真正的包装成一个债券。原因是一些风险厌恶型基金在基金章程里规定只能购买某种评级以上的债券。所以会有金融公司将资产证券化产品打包成债券出售。由于资产证券化在拆包之后会提高一部分小包(也叫Trench)的信用评级,低风险基金就能合法地购买实际上是高风险的金融产品。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
18天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
12天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
132 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
1月前
|
存储 分布式计算 关系型数据库
架构/技术框架调研
本文介绍了微服务间事务处理、调用、大数据处理、分库分表、大文本存储及数据缓存的最优解决方案。重点讨论了Seata、Dubbo、Hadoop生态系统、MyCat、ShardingSphere、对象存储服务和Redis等技术,提供了详细的原理、应用场景和优缺点分析。
|
18天前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
25天前
|
Cloud Native 持续交付 云计算
云原生技术在现代IT架构中的转型力量####
本文深入剖析了云原生技术的精髓,探讨其在现代IT架构转型中的关键作用与实践路径。通过具体案例分析,展示了云原生如何赋能企业实现更高效的资源利用、更快的迭代速度以及更强的系统稳定性,为读者提供了一套可借鉴的实施框架与策略。 ####
24 0
|
25天前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
51 1
|
1月前
|
监控 Java 微服务
从零构建微服务架构:一次深度技术探索之旅####
本文作为一篇深度技术分享,引领读者踏上自底向上搭建微服务架构的征途,旨在通过实战经验剖析,揭示微服务转型背后的技术挑战与解决方案。不同于常规摘要仅概述内容,本文摘要将直接以故事化手法,简述作者从单体应用困境出发,逐步迈向微服务化的心路历程,涵盖关键决策点、技术选型考量及实践收获,激发读者对微服务架构设计与实现的浓厚兴趣。 ####
|
1月前
|
Cloud Native 持续交付 云计算
深入理解云原生技术及其在现代IT架构中的应用
在数字化浪潮的推动下,云原生技术已成为企业转型的关键。本文将通过浅显易懂的语言和生动的比喻,带领读者探索云原生的核心概念、优势以及如何在企业中实现云原生架构。我们将一起揭开云原生的神秘面纱,了解它如何助力企业快速适应市场变化,提升业务的灵活性和创新能力。
|
1月前
|
敏捷开发 缓存 中间件
.NET技术的高效开发模式,涵盖面向对象编程、良好架构设计及高效代码编写与管理三大关键要素
本文深入探讨了.NET技术的高效开发模式,涵盖面向对象编程、良好架构设计及高效代码编写与管理三大关键要素,并通过企业级应用和Web应用开发的实践案例,展示了如何在实际项目中应用这些模式,旨在为开发者提供有益的参考和指导。
25 3
|
1月前
|
Cloud Native 云计算 Docker
云原生技术的崛起:从容器化到微服务架构
云原生技术的崛起:从容器化到微服务架构