多国扩展架构

系统的顶层架构约束,确保一套系统能支撑多国家、多运营主体的业务运营。


两层租户模型

graph TD
    SYS[统一系统平台] --> NG[尼日利亚]
    SYS --> GH[加纳]
    SYS --> TZ[坦桑尼亚]

    NG --> NG1[自营主体]
    NG --> NG2[合作资方A]
    NG --> NG3[合作资方B]

    GH --> GH1[自营主体]

    TZ --> TZ1[自营主体]
层级维度隔离什么共享什么
第一层:国家尼日利亚、加纳、坦桑…本地化配置(KYC/支付/货币/语言/监管规则)核心业务逻辑、系统代码、基础设施
第二层:运营主体自营、合作资方A、合作资方B…业务数据、客户数据、运营配置、品牌系统能力、国家级本地化配置

租户隔离原则

数据隔离

数据类型隔离级别说明
客户数据运营主体级每个运营主体的客户数据完全隔离,互不可见
交易数据运营主体级借据、还款、催收等业务数据按运营主体隔离
运营配置运营主体级产品参数、费率、活动、策略各自独立配置
本地化配置国家级KYC通道、支付通道、货币、语言等按国家配置
风控模型灵活基础模型国家级共享,各运营主体可叠加自有策略
系统代码全局共享所有国家和运营主体共享同一套代码

权限隔离

角色可见范围
平台管理员所有国家、所有运营主体
国家管理员本国所有运营主体
运营主体管理员仅本主体
运营主体普通用户仅本主体,按角色进一步限制

本地化差异矩阵

差异维度说明系统如何适配影响的系统
KYC 身份体系尼日利亚:BVN/NIN
加纳:Ghana Card
坦桑:NIDA
KYC 网关按国家路由到不同供应商和验证流程风控系统、客户中心
支付通道各国银行体系和支付基础设施不同支付网关按国家配置不同的通道和路由策略支付网关
触达通道各国短信/语音供应商不同触达网关按国家配置不同的供应商催收系统、消息网关
风控数据服务各国征信机构和数据源不同数据网关按国家接入不同的数据供应商风控系统
货币尼日利亚:NGN
加纳:GHS
坦桑:TZS
所有金额字段关联货币代码,按国家默认货币信贷核心、支付网关、全部涉及金额的系统
语言英语为主,部分国家有法语(科特迪瓦、塞内加尔)前端和触达内容支持多语言,按国家/用户偏好切换现金贷App、手机分期App、消息网关
监管与产品约束各国对利率上限、费率披露、催收行为等有不同监管要求产品参数(费率范围、期数等)按国家+运营主体配置,系统校验合规边界信贷核心(产品中心)、催收系统、运营系统

各系统的多租户适配要点

系统适配要点
信贷核心(6 模块)产品中心按运营主体配置产品参数;所有交易关联国家+运营主体标识;费率校验监管边界;账务核心按货币处理
风控系统决策流按国家+运营主体可配置;模型支持国家级和主体级叠加;外部数据源按国家路由
催收系统催收策略按国家+运营主体配置;触达合规规则按国家差异化;委外团队按国家/主体分配
支付网关资金方按运营主体管理;支付通道按国家路由;货币和对账按国家处理
渠道中心门店和SA归属到国家+运营主体;佣金规则按主体配置
运营系统所有配置项(产品/活动/策略)带国家+运营主体维度
客户中心客户归属到运营主体,严格数据隔离;KYC 通道按国家配置
消息网关触达通道按国家配置不同供应商;消息模板支持多语言
通用服务集成所有外采网关支持按国家配置供应商和路由规则

SaaS 模式考量(远期)

当系统对外提供给合作资方自运营时,还需要额外考虑:

维度说明
租户自助管理合作资方能自助配置产品、策略、渠道,不依赖我方操作
品牌定制App 和前端支持按运营主体定制品牌、Logo、配色
数据完全隔离合作资方之间、合作资方与我方之间数据严格隔离

全局标识设计

所有业务数据都需要携带两层标识:

每一笔业务记录 = 国家标识 + 运营主体标识 + 业务数据

示例:
├── country_code: NG          (国家:尼日利亚)
├── tenant_id: KR_NG_01       (运营主体:袋鼠金融尼日利亚自营)
├── loan_id: LN202603310001   (业务数据:借据号)
└── currency: NGN              (货币:奈拉)

这两个标识贯穿所有系统、所有接口、所有数据表,是多租户架构的基础。