浅谈银行内部户治理

文章来源：e路向上，文章仅供个人学习

年度工作计划对齐，财务会计部门对内部户提出了很多诉求，希望能通过系统进行有效控制，隔空论道终究效果有限，点状地见招拆招也不是系统性解决问题的好办法，正好借机会整体梳理一下。

什么是内部户

内部户是银行为满足内部账务处理要求，在进行业务处理时，需要使用的一类账户，该账户非为客户设立，仅为满足银行自身的作业要求。常见的需要用到内部户的场景有：

• 用于记录某一类资产的规模。这类内部户包括用于反映理财规模、票据不同类型贴现/转贴现、国债业务规模的内部户，对这一类内部户，在设计上一方面被用于记账，另一方面也被用于控制不要出现透支（设置内部户不允许出现负余额）；

• 以内部户方式记账的损益科目。典型的如存款应付利息、利息支出科目，贷款应收利息、利息收入科目，在实时交易过程中，常见的则有各类费用收入，如转账手续费收入，银承手续费收入等，常使用内部户方式记账；

• 用内部户方式记账的表外科目。如贷款转非应计后的应收利息，转入表外，银行承兑汇票开票、信用证开证、开立包含等的表外科目等；

• 各类资金暂挂账户。如银行的长、短款，存款账户转久悬后的资金暂挂、汇入汇款入账失败后的暂挂、资金派发失败后的暂挂等；

• 系统间往来账户。在分布式事务管理器出现之前，单体系统间进行账务处理，要满足有借有贷的会计平衡要求，设置过渡账户进行处理。举例：如贷款、存款系统为两个独立的系统，当发生一笔贷款放款时，为满足会计借贷平衡要求，一般会出现类似如下的分录，其中的系统间往来账户即为内部户：

  

• 机构间往来头寸。包括银行分行与分行之间、分行与总行之间的头寸往来账户，通常会设置为内部户。

  内部户与科目账的区别

在早期的银行系统中，个别厂商提供解决方案中，所有的总账科目都建立有分户，只不过是1对1，还是1对n的区别而已。并于此将内部户分为不同的类型，如一个科目、一个机构可以开立多个内部户的类型为A类，一个科目、一个机构只能开立1个，且需要实时更新余额的内部户为B类，仅在晚间更新科目账余额的内部户为N类等，诸如此类，不一而足。

回归业务本质来看，内部户从分类上与结算账户一样，本质是属于分户账的一类，科目账本身没有分户而硬设分户并将这个分户塞到内部户中，有画蛇添足之嫌。内部户与总账的关系示例如下：

对于这一“需要实时更新账户余额”类型的内部户，与对客户服务的分户系统类似，总账的余额更新需要根据交易流水，以加工后的日计表的方式计算借贷方发生，之后再更新余额。分户与总账之间需要进行总分核对。

内部户使用面临的一些问题

通过内部账户的设置和使用，解决了很多商业银行展业过程中账务处理的问题，比如汇入/汇出汇款过程中出现的暂挂落地问题，久悬不动户的挂账问题，现金长短款的挂账问题等等；也为系统从大集中向分布式过渡，保证单一系统满足“有借必有贷、借贷必平衡”的会计准则提供了办法。但是，如果不能根据内部户本身的特性因势利导，过度使用或者不能按正确的方式使用内部户，也容易导致一些问题，尤其是因为内部户是为某一类业务设置的特性，不能有效进行管理，极易导致内控合规风险发生。使用内部户过程中的常见问题或误区有：

1）、为非必要科目设置内部户。损益类科目、表外科目等均没有实时余额控制强要求的科目，按T+1方式更新总账账务即能满足账务处理要求，从必要性上看，为这一类科目设置内部户，实际上没有太大必要。

2）、依靠内部户余额变化控制业务规模变化。如在发行特定理财产品、大额存单、国债等产品时，用内部户来反映业务规模的变化，并在业务处理过程中，实时更新内部户余额。此时，因为内部户按机构设置，极易发生多笔业务同时请求更新一条内部户记录的情况，发生行锁，造成交易堵塞。

3）、在特定的业务场景中不合理地使用内部户。在一些颗粒度需要细化到“客户”一级的业务场景中，如本票解付等业务中（本票到期付款前，需要先将客户结算户中的资金先转入待解付账户），使用内部户作为解付资金的暂收账户，极易造成多个客户的资金混用，A的资金被用于B的本票的解付。

4）、需要挂销账的不做挂销账处理。银行资金处理过程中，资金错配、混用是非常大的忌讳（参考硅谷银行破产事件，以及国内各种理财产品暴雷后导致的火烧连营式的风险传染事件）。而内部户按机构（不是某一个客户）、按某一类业务（不是某一笔）设置的特点，导致极易出现资金池，发生将A的资金用于B，C的资金又用于A的情况。部分银行在业务处理过程中，不对这一类业务的内部户设置挂销账（专款专用，先挂后销），造成一本糊涂账，轻则对账费时费力，重则导致出现资金风险。

5）、不合理地设置内部户透支。为了资金安全，很多业务在记账处理时，通常需要满足先收后支，不允许透支的原则，尤其是一些居间代理业务中，银行代理从客户侧先扣取款项，然后再清算给第三方，此时，如果整个过程不能实现由系统自动处理，为满足清算时效要求，容易发生扣款还没完成，付款已经发生的情形，而这个需要满足的前提条件就是将内部户设置为可透支–方便是方便了，但易发生资金控制风险。

内部户治理的一些建议

内部户治理即根据内部户本身的一些特性（比如按机构、按科目设置，可以实时或准实时反映余额变化，一般不计息），有针对性地规避内部户使用过程中的一些问题。

1）、取消非必要的内部户设置。损益类、表外类科目根据业务特性，均不建议设置对应内部户，在记会计账时直接分录科目账。典型损益类科目的如存款应付利息、利息支出科目，贷款应收利息、利息收入科目、各类费用科目；典型的表外科目如银承的表外科目、保函签发对应的表外科目、信用证签发对应的表外科目等等。可以取消的原因有两个方面，一是直接由会计引擎分录科目账完全可以满足分录要求；二是其对应的业务台账，在对应的业务系统中有颗粒度更细的信息，无需通过对应的内部户来提供更多信息。（比如银承签发规模的信息，显然票据系统中有更详细的信息；信用证在国结系统中有更详细的信息…）

2）、取消控制业务规模的内部户，改为科目账，业务规模通过业务系统的额度进行控制。包括用于反映特定理财产品规模、大额存单、国债业务规模的内部户，对这一类内部户，部分银行的传统设计上一方面被用于记账，另一方面也被用于控制不要出现透支（设置内部户不允许出现负余额）。对这类内部户，建议的处理方法是取消内部户设置，直接改为科目账记账，而业务规模的控制及相应的查询服务由应用系统的额度或统计信息提供。这样的好处是，应用系统的额度信息在面对高并发、秒杀（比如特定理财产品搞活动，限时抢购）等场景时，可以将额度信息放入缓存，并避免使用悲观锁来规避交易堵塞问题，提高系统吞吐能力。

3）、在特定业务场景中，使用应解付账户替代内部户。在本票解付、信用证解付、票据解付等场景中，因为具体的解付操作是对特定客户而言的，因此，其解付款项来源，要么从具体的客户结算账户、客户保证金账户而来，要么是银行为特定客户提供的垫款，无论如何，其资金来源都是细化到具体客户的具体业务的。面对这种情况，为避免资金混用，最好的办法是为每个客户开设一个用途特定–用于解付的账户，即所谓的外户内用的账户–应解付款户。从结算户、保证金户或垫款而来的账户，均按不同的客户，划入这个应解付款户，实现专款专用。

4）、特定客户、特定业务的暂收/暂挂账户必须进行挂销账。针对资金暂挂类的业务，且非常明确有后续处理动作的业务，比如汇入汇款入账失败，需要落地处理的，在使用内部户时，建议配套挂销账进行处理。因为挂销账会涉及到挂账编号的生成，存储，并可能出现在A系统挂的账，由B系统来销的情况（即挂账编号需要在不同的系统间进行同步），其在IT实现上会比直接使用内部户更复杂一些，因此有些时候，开发工程师会以种种理由，引导业务不要去做挂销账，此处，建议业务要坚持自己的合理要求–在可行性没有问题的情况下，合理性就应该被充分考虑。

5）、不该设置透支的内部户，坚决不允许设置透支。此时，易导致的一个衍生问题就是，在业务操作中可能需要先付后收的业务操作，就变得没法处理了，但这正是一个通过约束条件反向push业务流程理顺的抓手–并不能以“存在即合理”为理由，为了流程上的妥协，而导致潜在的资金风险。

6）、不用内部户来支持存放同业、保证金等非主体账户。存放同业、保证金账户等在部分商业银行中，常用内部户来提供支持，但一方面存放同业、保证金均有非常确定的开户主体（存放同业的对手方也非常确定），另一方面，存放同业、保证金一般都会涉及到计结息，保证金账户更是涉及到回结单（企业保证金的账单还需要提供给对方做账），因此，使用内部户支持此类账户，将给操作人员带来大量的非必要操作，业务处理的效率也将大受影响。一般地，在进行系统规划时，存放同业和保证金最好作为单独的账户系统进行建设，其底层能力可以服用存款结算户。

内部户系统设计

内部户作为“核心系统–CoreBanking”的重要组成部分，天生是核心系统中的一个子系统，子服务或子模块。国内外的系统集成商，都有提供成熟的系统解决方案，此处不作特别赘述（毕竟也没几个银行真会选择从0到1自己全套自研核心的，极个别–如蚂蚁除外），仅特别探讨几个关键点：

1）、内部户的账户结构设计。集成商为了系统的普适性（大中小银行都能支持），账户通常会选择以varchar2（48）作为属性，结算户、内部户、存放同业户均从此结构，这个字段是可变长的，实际的长度取决于银行的要求，此时，行方的架构师在做选择题的时候，建议考虑几点判断标准：a、账号本身越简单越好，便于记忆及使用；b、账号本身尽量地包括更多信息，比如账户类型（区别于结算户、存放同业户、保证金账户）、所属科目信息等。账户结构的示例：

位置	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
取值	9	9	2	0	1	0	1	0	1	0	0	0	1	0	1	1
说明	专用识别码	科目号	账号序号，支持1个科目下可开立1万个（取决于业务规模）	分库分表位（非必要，不设置）	校验位

2）、考虑高并发性能问题。内部户因为按机构、按业务大类进行设计，导致单一内部户很容易出现行锁（多个交易同时请求悲观锁，造成交易等待）。为避免该问题的发生，对内部户入账类交易，或内部户是可透支的账户（如系统间往来），可考虑通过异步方式更新账户余额（当然，根本上还是要考虑银行业务量的实际，异步消息接口很多时候没有同步接口方便），另外，在进行内部户余额更新时，可以通过定时的借贷方发生额轧差的方式，将多次的锁请求，简化为一次（当然，发生额明细本身在加工账户交易历史时，是不能汇总的）。这里还有个原因，是内部户相比结算账户，少了大量的账户状态控制要求，或者可以简单地理解为，内部户除了被逻辑销户，基本没有其他状态，因此也就不需要在余额更新时进行各种账户状态检查。

3）、批量开立内部户的功能实现。内部户面向某一类业务，其在开设时，通常不会是面向某一个机构开立的，开设内部户通常会是所有机构都有这样的需求，因此，支持内部户的批量开设，可以有效减少操作人员的工作量。

4）、支持挂销账设计。内部户本身的数据模型设计，极类似一般活期结算户，但是，为了满足挂销账的需要，内部户系统在设计时，需要为挂销账预留出扩展性，即在某一内部户下，可以扩展出该内部户下的多笔挂账（已挂未销总金额 ≤ 内部户余额），挂账编号可通过内部户自身的挂账编号生成器进行生成。在销账时，内部户支持通过调用系统传入的挂账编号，进行全额或部分销账。

5）、分布式模式下的系统间往来的必要性探讨。在银行内部，一直有一条金科玉律，即“有借必有贷、借贷必平衡”，由此要求独立各个业务系统，在发生账务往来时，需要通过系统间往来内部户，规避掉单边借贷问题。但是，随着会计引擎和分布式系统设计下Seata、XTS等事务一致性保持组件的引入，系统间往来的内部户从原理上实际上已经不一定必要。其一，很多对存款户做了分库的银行核心系统，当发生跨库的账户转账时，并不会引入系统间往来，而是通过Seata之类的事务一致性工具来保证一致性；其二，跨系统的账务往来，本质上也可以通过全局流水号，对不同系统的借、贷进行关联，理论上也可以不用系统间往来内部户。

结语

内部户在银行系统中，属于业务属性较少，实现相对简单，原理也很容易讲清的系统，但管中窥豹，越是基础的东西，越能看出一家银行业务、内控的专业程度。对开发人员而言，弄清楚这样一些基础的知识，对进行复杂业务系统架构，统筹前中后台整体设计，为客户提供更好的服务体验，也将大有裨益。