Absa 的 SAS 信贷风险改造，不止于 Yahoo Finance 的标题

据 Yahoo Finance 报道，Absa 已将一项关键的信贷风险监控流程迁移至 AWS 上的 SAS Viya，将报告生成时间从数周缩短至数小时。这项变革以标准化云端工作流取代了手动脚本、孤立系统和本地计算。不过，更快的报告并不必然意味着更好的风险决策。

核心问题不在于云软件能否更快完成计算，而在于 Absa 能否在加快监控速度的同时，保留模型控制、数据沿袭、独立验证和人工判断。这些要求至关重要，因为模型输出会影响损失预测、资本规划和监管报告。

因此，Absa 正在检验大型银行面临的一个更广泛命题：一家机构能否在不削弱对每个模型审查力度的前提下，自动化模型治理中重复性的环节？SAS、AWS 以及竞争性的风险平台都对这个答案抱有兴趣。

Absa 实际做了哪些改变

Absa 以在 Amazon Web Services 上运行 SAS Viya 的自动化框架，取代了碎片化的监控流程。

该行此前的流程依赖手动脚本、独立系统，以及在本地基础设施上运行的大型代码批次。分析师需要从多个来源收集数据，处理数百万行记录后才能生成监控报告。

根据这份迁移案例研究，单份报告过去需要两到四周才能完成。搭建新的监控框架则可能耗时六个月到一年。这些延迟使得及早识别模型表现恶化变得更加困难。

当借款人行为、经济状况或底层数据发生变化，导致模型表现下降时，就会出现模型恶化。在某一经济时期校准的评分模型，当失业率、利率或还款模式变化后，可能会变得不那么可靠。

Absa 成立了卓越中心来重新设计这一流程。该团队为全行零售信贷模型制定了统一的报告、指标、可视化方式和接入流程。标准化之所以重要，是因为不一致的监控方式可能掩盖不同团队在阈值定义或问题升级处理上的差异。

该项目将工作负载从本地部署的 SAS Grid 迁移至 AWS 上的 SAS Viya。SAS 9 Content Assessment 用于盘点和迁移现有内容。SAS Cloud Analytic Services，即 CAS，提供分布式内存计算，使活跃数据保持可用，从而加快计算速度。

SAS Visual Analytics 为分析师和其他利益相关方提供仪表板。SAS Enterprise Session Monitor 帮助团队检查资源消耗并优化云端工作负载。这些组件共同构建了一条从数据处理到可视化审查的受控路径。

据报道，自动化流程可在数小时内完成模型监控报告。此前将大量时间花在执行代码上的分析师，如今可以转而调查结果、讨论异常情况，并为业务团队提供建议。

这一区别很重要。Absa 并未宣布一个自主系统如今可以在无人审核的情况下批准贷款或设定拨备。公开材料描述的是对模型监控、报告和支持性分析的自动化。

这则信贷风险更新为项目提供了简洁的新闻切入点。其底层实施更为具体：Absa 正在升级用于检查现有模型是否持续按预期运行的机制。

因此，这一 Absa SAS 信贷风险项目改变的是监督的速度与一致性。它并未免除该行在模型设计、验证、审批或补救方面的责任。

为什么信贷模型监控成了瓶颈

旧系统最大的成本出现在模型投产之后：团队需要及时证据来确认模型是否仍然有效。

银行在申请评分、账户管理、催收、资本计算和预期损失估算等领域使用信贷模型。每个模型可能依赖不同的数据、阈值、客户群体和经济假设。

监控团队会将实际结果与模型预测进行比较，寻找准确率下降、变量不稳定、总体特征变化、数据缺失，以及风险类别之间的异常变动。报告延迟可能让这些问题长期未被察觉。

随着银行增加产品和客户群体，工作量也会不断扩大。Absa 表示，其零售业务组合由数百个模型支撑。即使是可重复的月度或季度审查，只要每个模型都需要定制代码和手动准备，也会变得难以管理。

遗留基础设施可能进一步加剧这一问题。团队或许需要预留计算容量、按顺序运行批处理、核对输出结果，并手动重建图表。如果某个上游数据源发生变化，分析师可能要花费数天来诊断其影响。

公开案例研究显示，Absa 在 16 个国家服务 1,270 万名客户。规模扩大带来的不只是记录数量增加，也意味着产品、司法辖区、经济状况和数据控制方式的组合更多。

更快的监控周期可以帮助团队在模型漂移刚开始时就加以识别，也让分析师有时间在下一次正式报告截止日前调查原因。

但如果缺乏可重复性，速度的价值有限。若两名分析师使用不同的数据提取或代码版本运行同一测试，更快的计算只会更早地产生不一致的答案。因此，Absa 的标准化工作与其向云基础设施迁移同样具有重要意义。

该行的治理架构进一步印证了这一点。Absa 公布的模型监督架构显示，其 Models Committee 会在重大风险模型启用时及每年进行审批，同时监督模型风险偏好、调整、阈值、治理和保证工作。

无论计算在哪里运行，该委员会仍承担责任。云基础设施改变的是执行方式，并不会将责任转移给 SAS 或 AWS。

这一时机也反映出前瞻性损失估算日益加重的负担。IFRS 9 要求进行预期信贷损失，即 ECL，计算，利用历史、当前和预测信息估算可能出现的损失缺口。

该准则取代了通常在减值证据出现后才确认损失的方法。预期损失会计要求银行更早考虑风险恶化，从而提高了及时数据和受监控假设的重要性。

国际会计准则理事会发现，减值要求总体上能够更及时地确认损失。其 IFRS 9 审查也指出，披露和指引仍有可改进之处。

这正是 Yahoo Finance 标题所指向的更大运营挑战。信贷风险现代化并非一次性迁移，而是试图将模型监控转变为一个持续、受治理的流程。

SAS Viya 如何融入 Absa 的新流程

SAS Viya 通过整合分布式计算、共享工作流、仪表板和弹性云资源，加速了监控流程。

要理解 SAS Viya 如何运作，需要将分析平台与信贷模型本身区分开来。Viya 提供了数据准备、代码执行、工作负载管理和结果呈现的环境。它并不能保证每个模型都包含恰当的假设。

流程从借贷和账户系统的数据开始。这些记录可能包括余额、还款历史、客户属性、逾期事件和模型预测。团队必须在使用这些记录评估模型表现前进行验证。

CAS 将计算分配到可用的计算资源上。内存处理减少了存储与活跃工作负载之间的重复传输。当分析师需要反复汇总或测试大型数据集时，这种设计尤其有用。

AWS 提供的基础设施可在高负载任务期间扩展，并在任务完成后收缩。这种弹性可以减少对固定本地计算容量的依赖，但也带来了对资源配置和成本监控保持严格管理的新需求。

SAS Enterprise Session Monitor 让管理员能够了解资源使用情况。这些信息有助于识别低效会话、规模过大的工作负载或容量限制，也可支持对平台运行方式的内部审查。

Visual Analytics 将输出结果转化为仪表板。标准化仪表板能够以一致的格式展示绩效指标、阈值突破、数据质量信号和历史趋势。

价值来自于这些环节的衔接。如果计算虽能快速完成，但分析师仍需手动将输出结果转入电子表格，银行获益有限。端到端工作流减少了可能引入错误或延误审查的交接环节。

SAS 还推广一项自动化 Insights 功能，用于呈现潜在的分析发现。Absa 的案例研究提到了这项能力，但没有披露该行使用这些建议的频率，也没有说明它们如何影响决策。

任何自动生成的建议都应从属于正式模型控制。自动化观察结果可以将注意力引向异常模式，但无法判断该模式是源于数据错误、经济变化、政策决定，还是真正的模型弱点。

对“AI”一词也应保持同样谨慎。公开材料将 AI 和机器学习与更广泛的平台联系起来，但对于 Absa 监控流程中部署的具体 AI 模型，提供的细节有限。

读者不应将这一公告解读为生成式 AI 已开始治理该行信贷组合的证据。有据可查的提升主要来自自动化、分布式分析、云端容量、标准化报告和仪表板。

该平台还支持与 IFRS 9 相关的工作流。SAS 将其 IFRS 9 工作流描述为涵盖数据管理、模型执行、阶段分配、汇总和报告。

这些能力可以缩短生产周期，但实施选择仍然至关重要。团队必须围绕软件配置数据映射、访问控制、验证流程、升级规则和审批记录。

Absa 的 SAS 信贷风险项目似乎旨在减少这些活动中的运营摩擦。其成败将取决于该行是否将通用工具视为治理的基础，而非治理的替代品。

更快的报告让遗留风险平台承压

Absa 报告的交付周期，对仍将模型监控视为缓慢、手工拼装式控制工作的银行构成了压力。

主要竞争并不只是 SAS 与另一家软件供应商之间的较量，而是自动化、标准化监控与由脚本、电子表格、计划批处理和人工审查构成的机构特定流程之间的竞争。

这种较旧的路径也有优势。内部团队熟悉自身代码，可以直接修改，并避免将所有工作流都置于单一供应商的平台之中。专业模型也可能难以实现标准化。

规模越大，弊端越明显。定制流程可能导致定义不一致、代码重复、依赖关系未文档化，以及漫长的上手周期。经验丰富的分析师花时间维护执行流程，而不是解读风险。

共享平台改变了运营模式。中央团队可以定义通用指标和仪表板，而模型负责人则专注于模型表现。新框架可复用既有的数据摄取、控制和报告组件。

FICO、Moody’s、Oracle 以及云原生分析服务商等竞争供应商，也在满足同一市场的部分需求。有些侧重决策管理，另一些则聚焦风险计算、数据平台或监管报告。

银行也可以利用云数据服务、开源工具、笔记本和仪表板软件自行搭建系统。这种方式能够提供灵活性，但会将更多集成和控制工作交给内部工程团队。

Absa 报告的成果，为正在权衡这些选择的组织提供了 SAS 一个可信的参考案例。从数周缩短至数小时，管理层很容易理解这一改进，尽管案例研究并未披露实施成本或完整迁移所需时间。

比较范围也延伸至公共云服务商。AWS 承载了此次部署，但 Microsoft Azure 和 Google Cloud 也在争夺受监管金融工作负载。三者均提供数据、机器学习、安全和治理服务。

对银行采购方而言，问题不在于哪家云平台的功能清单最长。他们需要证据证明，工作负载能够满足内部风险政策、监管预期、安全要求和恢复目标。

Absa 的规模使该项目格外值得关注。该银行业务覆盖多个市场，并管理着庞大的零售业务组合。标准化系统必须能够容纳这些差异，而不能强迫每个模型套用不适合的模板。

这在一致性与本地判断之间形成了张力。通用指标有助于高级委员会比较模型，但本地团队可能需要针对特定产品或借款人群体增加额外指标。

设计良好的平台允许受控的差异化。它会保留必需指标，同时记录经批准的扩展。设计不佳的平台则可能鼓励团队为优化仪表板而努力，而非调查落在其范围之外的风险。

Yahoo Finance 的报道颇具价值，因为它让原本通常只会留在风险与技术部门内部的一项基础设施变革受到关注。不过，其竞争意义仍取决于可衡量的控制成果。

如果 Absa 能在保持验证质量的同时维持更快的报告速度，其他银行将不得不更严肃地审视漫长的监控周期。若该平台只是压缩了常规报告的制作时间，其带来的压力则会更有限。

SAS 还必须证明，在迁移团队离开后，该系统仍然易于管理。长期成功取决于升级、模型变更、员工培训、数据演进和审计要求。

最理想的成果不应只是一份快速生成的报告，而应是一套持久的运营流程，使 Absa 能够在连续报告周期中更早发现并修复模型问题。

案例研究未能证明的内容

已发布的证据表明周转时间获得了显著改善，但并未独立证实模型准确性更高或信贷损失更低。

主要来源是一篇由 SAS 与使用 SAS 软件的客户共同制作的客户案例。SAS 明确提醒，所述结果仅适用于 Absa 的具体情况，不应视为典型结果。

这一披露很重要。案例研究提供了有用的运营细节，但它并非独立审计、监管评估或受控对比。

材料未披露项目总成本、实施周期、人员需求，或需要修复的遗留代码规模。它也没有将新系统的总运营成本与原平台进行比较。

云弹性可以提升容量利用率，但并不保证支出更低。配置不佳的工作负载可能运行时间超过预期、保留不必要的数据，或消耗配置过大的资源。

公告同样缺乏服务级别数据。读者无从得知报告有多大比例能在数小时内完成、故障如何处理，或最快的结果是否适用于每一个受监控模型。

更重要的是，更快的监控并不意味着预测更准确。模型准确性取决于数据质量、方法论、校准、经济假设和验证。基础设施能够支持这些工作，但无法取而代之。

仪表板可以显示某项绩效指标已越过阈值。人们仍须判断这种变化是否显著、是否暂时，或是否由有缺陷的数据造成。

自动化也会引入自身的失效模式。标准化错误可能扩散至大量报告。错误的数据转换可能生成一致却具有误导性的仪表板。

因此，强有力的控制需要在源数据与分析输出之间进行核对。团队需要版本历史、访问限制、异常日志、可复现的运行过程和独立验证。

云服务集中度是另一项考量。高度依赖单一分析技术栈和单一基础设施供应商的银行，必须为故障、供应商变化和艰难的迁移做好规划。

这并不意味着云部署天生不安全，而是表明运营韧性必须涵盖平台依赖、身份系统、网络连接、恢复程序和员工知识。

数据驻留和跨境运营可能令设计更加复杂。Absa 在多个司法管辖区开展业务，每个地区都有自身的法律、监管和运营要求。公开案例并未说明哪些工作负载、国家或数据集进入了云环境。

该银行的年度报告档案为投资者提供正式的财务和风险披露。这些报告更适合用于长期评估减值、资产组合质量、治理和技术风险的变化。

即使是这些指标也需要谨慎解读。减值费用下降可能反映经济状况、贷款增长、资产组合构成、回收、管理层叠加调整或模型变更，不能仅归因于监控软件。

同样的限制也适用于资本准备金。更快的信息可以支持更好的决策，但准备金水平反映的是监管规则、资产组合风险、情景分析和管理层判断。

这种审慎解读并不会削弱该项目，反而界定了公平评估它所需的证据。报告的运营改善相当显著，而更广泛的风险收益仍属需要更长期观察来验证的主张。

因此，评估 Absa 的 SAS 信贷风险实施项目时，除处理速度外，还应考察控制质量。其最有价值的成果应是：当模型开始失效时，能够更早采取有文档记录的行动。

Yahoo Finance 报道后值得关注的内容

三个信号将显示，Absa 是否实现了持久的风险控制改进，还是主要完成了一次成功的基础设施迁移。

第一个信号是更快整改的证据。报告周转时间之所以重要，是因为它应帮助团队识别恶化情况，并在下一个报告周期之前采取行动。Absa 最终应能展示：从阈值突破、调查、审批到模型修正之间的间隔有所缩短。

这些证据可能出现在治理披露中，而非产品公告里。有用指标包括逾期模型行动的数量、未解决发现事项的存续时间，以及重大模型后调整的频率。

如果这些指标在模型清单扩大的同时得到改善，自动化监控的论据就会更有说服力。如果报告更快产出，但整改仍然缓慢，那么瓶颈只是转移了位置，而没有消失。

第二个信号是围绕新平台的保障质量。内部审计、外部审计和模型验证团队应测试数据血缘、访问控制、代码迁移、变更管理和报告可复现性。

顺利迁移并不保证控制能够持久有效。平台升级、新数据源和模型修订都可能引入新的错误。Absa 必须证明控制措施会持续运行，而不只是在实施期间有效。

出现重大控制失效的证据将削弱该项目的核心承诺。若有证据表明团队能更早发现并解决较小问题，则会支持这一承诺。

第三个信号是扩展至初始监控范围之外。SAS 表示，该框架旨在实现可扩展性和更快上手。下一项考验是 Absa 能否在不重建漫长实施周期的情况下，将更多模型纳入该框架。

扩展应保持选择性。某些模型可能需要专业测试或针对特定司法管辖区的处理。银行不应仅为提高单一平台覆盖的模型比例，就牺牲恰当的监督。

与快速宣称实现全面覆盖相比，循序推进且记录例外情况的部署方式更具说服力。标准化在澄清差异而非掩盖差异时最为有效。

读者也应关注 SAS 在未来更新中如何描述此次部署。若能提供更多关于模型覆盖范围、控制成果、工作负载可靠性和分析师生产率的细节，相关主张将更易评估。

Yahoo Finance 的报道揭示了一项有意义的技术转变，但决定性证据将在迁移新闻热度消退后才会出现。信贷风险系统通过在不断变化的经济和运营条件下持续展现表现来赢得信任。

对银行技术负责人而言，眼下的行动很直接：比较制作监控报告所花的时间，与调查报告发现所花的时间。然后追踪每一次会延迟审查或削弱可复现性的人工交接。

对投资者和客户而言，更好的问题不是 Absa 是否采用了云分析。应当问的是，该银行是否能更早识别表现走弱的模型、更清晰地记录决策，并更快解决例外情况。

Absa 已表明，一份监控报告可以从数周缩短至数小时。现在，它必须证明，节省下来的这些周数能够持续带来治理更完善的信贷决策。