1、前言
当我们在讨论多法人的时候，我们本质上在讨论什么？银行科技中我们经常谈到多法人场景有：省联社与农商行的关系、母行与村镇银行的关系、软件服务提供商与多个租户之间的关系，稍微总结归纳一下就可以得出：多法人讨论的背景是，基于科技能力、建设成本、管理体系等因素考量，如何通过一套科技体系对多个法人提供科技支撑的能力？
站在系统开发的角度，我们本能的要求业务的逻辑越是清晰、简洁、明了越好，而面对多法人的业务则是不论主动还是被动、无论情愿还是不情愿，都是要把多个法人的需求揉到一套科技体系中去考量。与单一法人对比多出来的这个维度是科技部门需要解决的，如果把这个复杂度加到运维体系中，则可以考虑多租户、多实例的模式来应对，其成本和工作压力给到了运维部门；如果把这个复杂度加入到研发体系中，则可以考虑PaaS模式、SaaS模式，其成本和工作压力给到了研发部门，总而言之，业务有需求，科技来满足。
2、多法人的总体目标
既然科技是满足业务的，那么多法人的业务目标是啥？说到这里忍不住想吐槽，碰到过太多的目标混乱、缘木求鱼的破事，一件事情安排下来，背景是啥？不知道。目标是啥？自己理解。客户诉求是啥？网上查……反正我就要一个解决方案！我真想站在世界之巅，大喊一声，I'm superman。本以为吐槽完心中会舒爽一点，然而并没有，但是生活还要继续……我们接着说多法人：多法人的目标是啥？如果我们考察的对象足够多，会发现在不同业务背景下多法人的目标是不一样的：
- 对于村镇银行，多法人的诉求可能是统一管理；
- 对于法人集团，多法人可能希望资源共享；
- 对于省联社，多法人的诉求是集中管理与业务隔离；
- 对于农商行，多法人的诉求是业务个性化能力；
- 对于科技部门，多法人的诉求是较低的系统复杂度和运维成本
- 对于监管部门，多法人要求数据隔离
……
隔离&共享、统一管理&个性化能力、系统复杂度&运维成本……天呐，全是对立的！这题太难了，我能不能不做？（雪花飘飘、北风呼啸……），有人的地方就有江湖，有江湖的地方就有利益冲突，多法人的目标咋定，关键看你的屁股坐在哪儿。我既想业务共享又想业务隔离咋办？出门右转，百度搜索“幻想症如何治疗”。当然我们还是要简单总结几个目标的，不然让人以为我是骗子🤥，这几个目标就是我们上面提到的几个关键词，不同的是要加上限定语：
- 资源共享：多法人的基础其实是共享，如果没有共享就没有拿到一起讨论的必要。资源可以是业务资源、渠道资源、客户资源、科技资源，资源共享是多法人讨论的隐含背景，当分歧大于共享时，这个话题就应该打住了。
- 业务多元：求同存异是周总理解决多国争端的大原则，当然同样适用于多法人。业务多元化也叫个性化，不管是邦联制还是联邦制都要有地方法律，不管是省联社统一管理下的农商行，还是集团统一管理下的村镇银行，业务都有可能出现差异，甚至同一法人下不同机构业务也可能不同，当我们说到参数化、配置化、灵活性、个性化这些内容时都是对业务多元化的支持，所以从这个角度来说，所谓多法人“只不过”是参数化的一个维度。
- 监管要求：我们对监管简直是又爱又恨，看到别人打监管的擦边球获利时恨不得到去举报别人不守规矩，就盼着监管收紧，美其名曰控制风险；当自己蠢蠢欲动时，又自我安慰业务创新不容易，水至清则无鱼国家不会不懂，祈祷监管睁一只眼闭一只眼。扯远了，具体到多法人，监管主要体现在对隔离性的要求，但是隔离到什么程度自己去体会。
- 成本最优：这是科技部门最关心的，不管是通过部署多实例降低系统复杂度，还是通过PaaS和SaaS使用一套实例节约运维和硬件成本，最终目标还是实现成本最优，选择哪种技术路线其实是寻找成本的平衡点，当多法人共性多于个性时，SaaS似乎是一个不错的选择；当个性大于共性时，多版本部署貌似也没那么讨厌了，没有一成不变的原则，顺势而为方证大道。
3、多法人的业务需求
多法人的需求是一个伪命题，因为我们不能抛开具体业务泛泛而谈多法人如何处理。多法人的需求是要深入到业务流程如何制定、参数如何配置、计算规则如何不同、标题和logo如何展示的颗粒度的，所以这是需要每一个业务系统的每一个功能点在讨论需求的时候都要考虑到的问题。在需求实现层面，主要考察点就是我们上面提到的，共享和隔离。我们要问业务人员（或者自己体会，你懂的）：这个业务对象不同的法人业务逻辑一致吗？业务逻辑一致不代表没有个性化，只不过个性化可以通过参数的配置进行了一致性处理。如果不一致哪里不一致？运营流程、计算规则、页面展示、操作模式还是业务规则？我们根据银行业务架构和Bank3.0应用架构分层模型，将银行常见业务对象进行总结，并分析其对多法人的支持能力。
3.1、运营层业务对象
-
组织机构
我们把组织机构放到第一位说，主要是因为机构的架构体系其实很大程度上决定了多法人的业务架构体系。对于集团模式统一管理的多法人体系，其管理职能一般都由集团统一承担，业务共享化程度也比较高；对于各自独立运营的多法人体系，上层没有统一的管理，管理职能由各自承担，业务共享化程度低，也就意味着其产品、参数、客户、核算都相对独立，完全由本法人运营和管理。 -
客户
客户是个比较敏感的话题，客户在同一家行的不同网点都可能存在竞争关系，在利益的驱动下客户的共享度注定不可能高。但是如果多法人是集团模式，出于客户数据统计或者风险管控考虑又需要对同一客户做身份认定，这就有两种管理模式，一是同一客户在不同法人下客户号不一致，这种方式的隔离度较高，逻辑较为简单，但是需要对客户一致性关系绑定，以实现特殊场景的客户要求。二是同一客户在不同法人下客户号一致，这种方式从数据源头对客户做了身份一致性认定，但是在客户识别和基于客户号的查询时需要增加法人维度。其它客户信息的采集、管理、分析、使用一般都是按法人隔离的。 -
产品
产品的管理和机构模式关联性比较大，集团模式下产品由集团统一管理，产品在创新、设计、开发阶段不按法人区分，在面市阶段才通过对法人的差异化上架实现产品的差异化，个别不一致产品可通过对法人的独立上架实现，这种模式的优点是产品总数少、维护量小。对于独立运营模式产品从创新、设计阶段就要按多法人隔离开，基本需要实现产品运营的完全隔离，不过产品的运营分散到各个法人，各法人只需要维护自己的产品，量级不会太大。
产品中还有一个常见的子业务对象：产品额度。对于基金、理财等投资理财类产品是有额度管理，对于多法人而言需要支持集团共享额度、法人专用额度，以及按照组织架构的多级额度分配机制。 -
交易
交易中心是Bank2.0提出来的概念，是把原来分散在各个业务系统中的标准化的对客销售的流程进行了抽象。多法人对交易的要求主要体现在产品的可见性和数据记录的完备性。产品的可见性是对于不同的法人应当可以销售上架到自己货架的产品，包括本法人创建的产品和代理其它法人的产品；数据记录的完备性是交易中心本身起到了交易流程串接和交易数据场景存储的的作用，在bank3.0的架构体系下，业务流程中后续的对账、过账、事后分析等环节都是以交易中心作为数据源，所以交易中心中记录的多法人数据要能满足后续业务过程的需要。典型的业务场景是A法人代理B法人的产品，交易中心需要将产品所属法人和销售法人记录清楚，以便于实时结算与事后清算。 -
计价
银行业务中的计价包括费率、税率、汇率、税率。从系统实现层面而言，计价可以简单归纳为一个按照事先定义的计价因子执行计价规则的规则引擎。一般而言计价支持两种模式，基础价格和优惠价格（差异化价格），基础价格是面向所有交易的，差异化价格的的维度可以根据机构、渠道、客户等单独制定。所以对多法人而言，计价主要是两块，一是是否需要集团统一维护基础价格，还是法人独立维护；二是在差异化维度上增加法人维度。 -
风控
法人独立运营模式，风控与单一法人处理逻辑一致；集团运营模式，会有集团下对客户统一风控的要求，在授信额度、授信审批流程等过程中需要考虑跨法人的业务数据。 -
核算
多法人的核算关注点是否支持多法人多科目体系，也就是多帐套，是否支持多会计准则？如果有全行统一的会计引擎，一般可以通过规则可配置化的引擎实现从业务要素到会计科目的映射，这种情况只要把法人纬度作为一个规则条件即可。但是如果没有会计引擎，核算还比较分散的情况下，那就要考虑在每个有会计核算的系统实现针对性的功能开发。 -
员工
多法人对员工没有特别的要求，但对于角色和权限可以做一些优化处理，比如集团模式下可以考虑角色跨法人统一管理，在传统的用户角色权限模式之外，增加法人和权限的授权关系，通过两条线撮合出用户执行权限，从而实现同一角色，在不同法人下的差异化，简化授权。 -
参数
参数有两类，一类是技术参数，一类是业务参数。参数是共享还是个性化需要根据参数依附的业务对象具体分析，不能一刀切。 -
基础服务
基础服务主要是影像，安全平台，内容管理平台，电子回单，电子印章……等这些基础性的技术系统，一般情况下多法人是个业务概念，基础平台是不需要区分多法人的，当然其后管系统还是要按法人隔离。
3.2、渠道层业务对象
- 视图
对渠道系统而言，其业务逻辑大部分调用后台服务，只需要识别法人标志，并传递给后台，重点需要处理视图层的多法人差异性，比如展现风格，logo，门户等视图层的内容。
3.3、流程层业务对象
- 业务流程
业务流程有两种，长流程BPM和短流程BIP。在企业级架构中，业务流程是面向客户和场景差异化的内容，从架构层次上来说是面向机构、渠道、客户等维度差异化的，但是从技术实现上，流程的基本走向是基于流程引擎在开发阶段实现的，如果有多法人差异化需求，要在流程节点中增加对多法人的判断逻辑。 - 集中作业
集中作业主要考察多法人是建设一个集中作业中心还是多个集中作业中心，中心的人是一套班子还是多套班子？
3.4、账户层业务对象
- 资金清算
资金清算恐怕是多法人架构体系中最难讨论清楚的话题了，清算账户怎么开？是否支持法人间通存通兑？支付结算系统怎么支持？是否需要建设独立的法人间清算中心？头寸如何管理？清算路径如何设置？法人内清算和法人间清算模式有何不同？对负责清算的系统有何要求？片言难以论清，那就暂且放过它。
3.4、数据层业务对象
- 统计分析
无论是集团模式还是独立运营模式，统计分析一般情况下都是以法人内为单位的，除非个别场景需要进行跨法人统计时，才会进行汇总统计。 - 监管要求
监管要求，一个是报送上，是以法人为单位进行报送的；一个是数据隔离上，监管上建议按照法人为单位进行数据隔离。
4、多法人的应用解决方案
4.1、多租户与多法人
- 多租户是一种应用服务模式，多法人是一个业务关系。
我们在讨论多法人时，都会不可避免的谈到多租户，但是说到多法人与多租户的关系，可谓五花八门、没有定论。简单看一下百度百科上多租户的定义：
多租户技术（英语：multi-tenancy technology）或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。
多租户简单来说是指一个单独的实例可以为多个组织服务。多租户技术为共用的数据中心内如何以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。
技术上，多租户技术可以通过许多不同的方式来切割用户的应用程序环境或数据。数据面（data approach）、程序面（application approach)、系统面（system approach）。
从这个定义上不管是IaaS、PaaS还是SaaS架构都可以说是多租户技术；还有一种看起来比较low的选择，为差异化较大或者规模较大的客户单独部署独立的软硬件环境，虽然不是一套应用，甚至不是一个应用版本，但是的确为多个客户提供了同类服务，称为多租户也无可厚非。所以如此看来，多租户是一种技术路线的选择，通过不同的层次实现客户的隔离。
而多法人是一个业务概念，描述的多个法人实体的业务关系，而这种关系可以通过多租户的技术体系进行支撑，举个栗子：完全独立的法人可以通过IaaS层的租户架构体系实现数据和应用的隔离；集团统一管理的法人通过SaaS的租户架构体系实现业务的隔离和部分共享。
4.2、分行模式与法人代码模式
- 将复杂度放在数据初始化还是在使用场景
多法人的技术实现路线上有两个选择，准分行模式和法人代码区分模式；对业务的满足度上，二者没有区别，都是要根据业务需求实现；不同的是分行代码模式是基于组织架构不进行大调整的前提，但这种演进派的折中做法为后续多法人场景的区分带来麻烦。从系统和数据的逻辑清晰度来看，法人代码模式都是要优于准分行模式的。
4.3、法人代码的传输
- 报文头中增加法人代码
多法人是全行级的业务概念，对多法人的处理也需要应用架构层级的解决方案。具体而言，需要将法人代码的概念贯穿系统全生命周期。从参数设置、到系统访问、报文传输、服务提供、界面展现的应用处理全流程，都要体现出法人属性，即使在个别场景没有用到。
所以对于渠道而言，就需要在任何一个发起场景都传输法人标识，对于内部用户登录的系统，可以直接通过用户所属机构识别法人；对于外部客户使用的系统，客户登录前是无法区分法人的，这对于某些法人特色的产品促销和资讯有造成影响，对于web端可以通过不同的域名来区分，对于App端考虑是否可以通过上次登录历史或者终端缓存区分；客户登录后，如果只在单一法人下开户，则直接登录，如果在多个法人下都有客户、账户，则需要客户手工选择当前操作的 法人。
对于后台应用而言，所有的服务中都增加了法人标识，由于是共性的，可以增加到报文头中统一传输，对于不区分法人的场景不使用即可。
4.4、数据的隔离与共享
数据隔离的不同级别，对应云服务的不同层次，当然根本上还是为了满足业务的需求和科技的诉求。
- 物理隔离
对应IaaS架构体系（或未实现云化架构体系），为每一个租户分配独立的硬件与网络资源，部署独立的应用，隔离级别最高，如果应用版本再不一致的话，其实就和传统的定制软件开发没有区别了。 - 实例隔离
对应PaaS架构体系，共享底层资源，为每个租户建立独立的数据库实例或表实例，就是我们常说的分库分表。数据库实例隔离的模式下，应用实例可以是独立部署的（PaaS）也可以是集中部署的（SaaS）。相对磊说，隔离程度也比较高，完全满足监管需要。 - 逻辑隔离
逻辑隔离是在SaaS架构体系下数据层常用的方式，简单说就是在表中增加法人字段进行数据访问区分，对数据权限的控制和使用的准确性都交由了应用层去实现，隔离性较低。 - 不隔离
对于多法人共享的数据，比如一些系统参数、技术参数、运维数据等是不需要区分多法人的
4.5、服务的隔离与共享
- 写入的服务
从报文头中拿法人参数，写到需要区分法人的场景中。 - 逻辑处理的服务
逻辑服务如果实现了法人参数可配置化，则需要在执行过程中根据参数配置实现逻辑分支的判断。 - 读操作的服务
正常情况下都需要根据法人标识对数据进行访问隔离，可以在技术平台层对这类服务统一处理。特殊场景需要跨法人的，特殊处理。
后记
回家的火车上零零碎碎敲了一半，到家撬开眼皮敲了另一半，感受只有一个字，困。
