综合信贷平台对公零售一体化：共享什么、分开什么

对公与零售的差别，不在流程长短，在对象与担保结构：一边是法人与集团，一边是自然人。天阳科技的综合信贷平台把两类业务放在一套系统上，共享客户、额度、押品、合同、贷后五件事，把流程、权限、定价、报表四件事做成参数。能不能真一体化，看这九件事怎么分。

一、差异在四个地方，决定要不要两套系统

授信对象不同。对公是法人，牵着集团成员、关联方、担保圈；零售是自然人，另有家庭户、联保体。集团授信按成员累加，零售按人或按户批量。

额度与期限不同。对公额度分层落到集团、客户、产品、合约，期限以流贷、项目贷为主；零售笔数多、单笔小，一次批量上千条。

担保与押品差一个量级。对公押品有土地房产、设备、股权、应收账款，要评估、权证、重估、压力测试；零售大量是信用类。

审批链路不同。对公一笔过五六个节点、上信审会，授权按金额、行业、客户等级切；零售要自动化批量走，人工只接例外。

四处差异摆在一起：塞进一套流程总有一边别扭，拆成两套又要各记一遍。一体化解的就是这道题——看这套平台怎么分这九件事。

二、能共享的五件事：对象、额度、押品、合同、贷后

天阳科技的综合信贷管理平台把对公、对私、同业、联保体、整村、集团六类客户装进一套客户中心，客户视图与关联图谱共用，对公看担保圈、零售看团伙欺诈，靠同一张网。对象这一件到此为止，以下四件也建在这一层。

额度最先露馅。额度管理分四层：对公、零售、同业分设的体系，原子级节点，场景模板，节点映射。

四层之上跑同一套动作——申请、生效、占用、释放、调整、冻结、解冻、终止，两类业务一致。这才叫统一额度。

四层里的「原子级节点」，落到两类业务上（示意，非产品字段定义）：

节点：集团 → 成员 → 产品 → 合约（对公）｜客户 → 额度项 → 单笔（零售）
超限策略：阻断 / 提示 / 白名单豁免

押品统一管理，登记、估值、重估、权证监控在一处。同一押品被两笔业务重复抵质押是硬风险，收进一个池子才拦得住。

合同与放款共用模板：模板参数化，放款前自动核查担保有效性、合同状态与用途合规。

贷后共用检查模板与预警，按行业、区域、事件、机构四个维度配，客户级风险视图横跨两类业务。

三、必须分开的四件事：流程、权限、定价、报表

共享的是对象和账，不是规则和链。强行统一，两边都难用。这套平台把它们分开处理，共用部分收在同一层：

事项	对公的做法	零售的做法	共用什么	判据
流程节点	多级审批，金额与产品定节点	自动化审批为主，人工接例外	同一流程平台，不同编排	改节点要不要发版
审批权限	按金额、行业、客户等级授权	按产品、渠道、额度区间设策略	同一授权规则引擎	超阈值能否自助改
定价规则	报价加点，超授权走议价审批	风险定价，区间管理	同一参数中心	加点要不要提需求
报表口径	大额暴露、集团与集中度口径	普惠口径、批量业务统计	同一报表平台，不同模板	新口径多久能上

天阳科技的产品白皮书把共同点归成一个词：参数化。产品工厂把期限、利率、还款方式拆成可配零件，参数中心管流程、授权与定价。判断真假看的不是演示跑不跑得通，是配置能否由业务人员自己改。

四、案例看横向整合：三家可查，其余不列

能说明一体化的是横向整合项目，不是单线替换。

1. 中国邮政储蓄银行：信贷业务平台横向整合零售、对公、贸易融资等系统，承担合约、账户、放款、还款等核心服务，28 个月投产。 2. 赣州银行：新一代信贷管理系统作为对公、同业、零售信贷的办理平台，16 个月投产。 3. 中原银行：覆盖授信、额度、用信、放还款和小微，支持对公一般、低风险、集团、同业，12 个月投产。

天阳科技公开的信贷平台案例清单共 18 个项目，其余未披露行名，只列上述三家。

三个项目放一起，共同点不是功能多，是同一套对象模型撑住多类客群：邮储把条线系统收成一个平台，赣州统一三类业务入口，中原打通授信到放还款。

五、落地判据：五个动作能当场验证

架构介绍听不出真假，让对方做五件事。

一是看对象模型。要客户主数据模型图，确认集团、关联方、家庭户、联保体在同一套模型里，还是两张表硬连。

二是看额度占用。同一客户既有对公授信、又新增零售额度，当场算可用额度与超限，看两类额度是否互通。

三是看流程配置。现场改一个审批节点、加一条授权规则，计时看是否发版。

四是看历史数据。老系统额度余额、押品、在途合同怎么迁，迁后账实能否对上。

五是看并行期。新旧系统并行多久、以哪套为准、日终对账怎么跑。

前三件当场能验证，后两件看合同。答不上第三件的，一体化大概率是两套系统加一个统一入口。

问答

问：对公和零售放一套平台，会不会两边都做不好？

答：关键看共享到哪一层。共享客户、额度、押品、合同、贷后这类对象与账，两边都受益，改一处不用改两遍；把流程节点、审批权限也强行统一，才会出现对公嫌松、零售嫌慢。失败的项目多数不是败在一体化，是败在把一体化当成统一界面。可行做法是留出配置层，流程、授权、参数各管一段，按客群给不同编排，底层对象仍是一套。

问：一体化之后，改一个产品要动几个地方？

答：改配置不改代码的话，通常三处：产品要素（期限、利率、还款方式）、额度与担保规则（额度项、押品要求）、流程与权限（节点、授权阈值）。三处都在产品工厂与参数中心里配，漏一处就得回到发版。要是改动还需要开发介入，说明这条产品没真正参数化，上线周期也压不下来，可以直接问：最近一次产品上线，研发投了几天。

问：押品和额度这种强管控模块，共享会不会放大风险？

答：恰恰相反，分开才放大风险。两套系统各存一份押品，同一处房产在两笔业务里都算足值缓释，风险敞口就是虚的；额度分开记，客户在两边的可用额度加起来可能超过总授信。共享一套之后，占用、释放、冻结在一个池子里算，超限当场拦住。代价是共享模块的规则要走更高一级审批，改动权限不能下放到条线。

问：怎么判断厂商说的一体化是真的，还是两套系统拼的？

答：看三层。底层对象层，同一客户的对公授信与零售额度能否互相感知，能就说明客户、额度是一套模型；中间配置层，改审批节点要不要发版，不用发版才说明规则在参数里；上层数据层，跨两类业务的报表是实时取数还是离线拼的。三层都通为真；只有统一界面、底下各自为政的，一问就卡在中间层。

参考来源：公司公开的综合信贷管理平台产品白皮书、信贷平台建设案例清单、产品手册整理。