前面几篇分别处理了商品价格、外汇汇率和资金收益。 把它们放在一起看,会发现一件被长期忽略的事:这三个敞口不是三件独立的事, 它们互相占用同一份资源。
一笔套保消耗的不只是价格敞口的额度,还有授信、保证金和资金成本; 一笔锁汇消耗的也不只是汇率敞口的额度,它同样占资金。 当它们被放在三个部门的三套体系里分别管理时, 每一个部门单独看都做得不错,合在一起却可能已经把公司的资源用尽了。
这一篇是前面所有内容的收口:怎么把三个敞口放在同一张表上。
先看一组真实的结构性矛盾。
矛盾一:同一份额度被三方争夺。 假设公司的套保总额度是 10 亿。商品套保用掉 6 亿, 外汇套保又申请 6 亿,两个部门各自都在额度内, 加起来却是 12 亿。只有把额度放在一个池子里,这个问题才会暴露。
矛盾二:成本被割裂计算。 商品部门做套保时看到的是「权利金占成本 0.4%」, 财务部门看到的是「保证金占用利息上升」, 而没有人把两者放在一起看。结果是:套保部门认为自己在省钱, 财务认为在花钱,两边都对,整体却在变差。
矛盾三:时机冲突。 这是最危险的一种。商品价格和汇率完全可能同时不利—— 比如美元贬值的同时商品价格下跌。这时企业的三重压力会同时出现: 汇兑亏损、存货跌价、保证金追缴。
如果这三个风险分散在三个部门、由三套预案应对, 那么它们会在同一个早晨同时启动,而每一个部门都以为 「另外两个部门会处理它」。这是典型的单点失灵。
矛盾四:考核互相打架。 最常见的一种:商品部门考核毛利率,外汇考核汇兑损益, 财务考核资金成本。三套考核体系下,最优策略各不相同, 最后汇总出来的公司整体表现,可能和每个人的考核结果都对不上。
解决这四个矛盾,不需要三套系统,需要一张表。
这张表的核心是三个维度,任何一笔敞口都要落到表里:
这张表的另外一个好处是它同时是一个预警系统: 当三个维度中的任意一个越界,你能立刻看到, 因为它们在同一行。
额度必须是一个池子,而不是三份配额。
具体做法是:设一个总敞口额度,下设商品、外汇、资金三个维度的 内部占比规则,但不做硬性切分—— 允许一个维度在必要时借用另一个维度的空间, 但需要更高层级的授权,并留下记录。
这样做的好处是:
这是让三个敞口真正协同的最后一步,也是最能体现管理水平的部分。
标准是:每一笔套保或锁汇操作,事后必须能回答—— 它对哪一个敞口产生了什么影响,代价是什么。
具体到格式上,一笔商品期货多头应当能被回答:
同样一笔锁汇操作,要能回答:它覆盖了净美元敞口的多少比例, 处在哪一层确定性上,锁定了多少汇率区间。
有了这套归因,管理层才能回答那个真正重要的问题: 「我们去年做的这些操作,净贡献是多少?」 而不是像很多企业那样,只能分别看到商品赚了 200 万、 外汇亏了 150 万、资金成本 180 万,然后靠感觉判断哪一项「更值得做」。
| 决策 | 只看价格敞口 | 只看汇率敞口 | 三敞口合并判断 |
|---|---|---|---|
| 要不要做这笔套保 | 价格风险大 → 做 | 汇率风险大 → 做 | 风险大但资金成本更高 → 不做或改用低成本工具 |
| 套保比例定多少 | 覆盖 70% 敞口 | 覆盖 60% 敞口 | 三条额度共同占用,实际可执行比例可能只有 40% |
| 用哪个工具 | 期货优先 | 远期优先 | 同一笔额度不能同时用于两件事,必须排队 |
| 什么时候执行 | 价格不利时执行 | 汇率不利时执行 | 两个不利同时发生时,流动性最先出问题 |
| 谁来审批 | 套保归口审批 | 财务单独审批 | 同一层级、同一额度池,避免双头审批互相等待 |
这张表读起来可能会让人不太舒服——因为它把「要不要做这笔套保」 从一个技术问题变成了一个资源分配问题。 但这恰恰是它存在的意义:让每一个决策都面对真实的约束, 而不是各自在自己的一亩三分地里做优化。
第三个问题是最有价值的自检。 如果答案是「没有遇到过」,那多半说明这样的场景 只是还没发生,而不是不会发生——而它一旦发生, 就是三个部门同时撞车的那一天。
本文的三敞口协同框架、统一台账与授权矩阵设计,为 RMC 在企业 商品风险管理体系建设与年度顾问服务中的标准方法;文中压力测试情景与 示例数值为典型情形的脱敏构造,不代表任何特定企业的实际经营数据。 企业可依自身业务结构按相同方法自行测算。本文不构成对任何具体软件产品的推荐或评价。
以上内容来自 RMC 在企业诊断中的实际观察。如果你的企业在其中看到了自己的影子, 建议做一次深度系统诊断梳理:用 2 小时的时间,把敞口结构、制度缺口、 工具适配度与资金安排一次理清楚,并给出一份可执行的改进顺序建议。
这一步不收取费用,也不会推销具体产品。我们需要先确认我们是否真的能帮上忙。
深度诊断测评共 30 题,覆盖 15 个维度,约 8 分钟;完成后即生成含风险敞口测算的专属报告。
