数字化时代下的核心银行转型.pdf

数字化时代下的核心银行转型 数字化时代下的核心银行转型2存款和贷款是零售银行和商业银行的主要业务。然而，这些核心业务正不断从传统系统流失，束缚了银行快速创新的脚步，亦妨碍了银行响应客户对日益数字化和定制化体验的需求。银行在提升运营透明度和实现效率最大化方面也面临着较大的压力，而这需要向运营和监管利益相关方提供相关实时信息。越来越多的金融科技公司在市场上大获成功，对传统银行形成威胁，或将颠覆其传统的业务模式。好的方面是，银行在过去十年间专注于应对各项合规要求，而如今已将重点转回到增长上，这种增长须基于能够提供更敏捷、更灵活的创新产品和定价方案的业务线。尽管银行迄今为止的数字化转型一直强调前台职能和客户渠道，但未来提供下一代产品和服务，还需推进核心银行系统的数字化转型。随着核心银行系统数字化的推进，银行需要考虑变革步调以及现代化进程带来的影响。除技术外，银行还需考虑核心系统现代化对员工队伍的影响从基于供应商的服务模式以及依靠日显不足的技能来支持传统的定制应用程序，转向由配置和应用程序接口（ API）驱动、以云计算为基础的解决方案。最后，在推进数字化转型的同时，银行还需维持日常运营和服务水平。3数字化时代下的核心银行转型除了少数例外 ， 大多数美国顶尖银行的核心银行操作均应用的是二十世纪八九十年代部署的旧系统 。1这些系统或是自主研发 ， 或是高度定制以致不再与购买的初始供应商产品类似 ， 导致维护复杂性加大 。银行早就意识到这些系统需要实现一定程度的现代化 ， 但直到最近才开始考虑对此投入大量时间 、 精力和资金 。 以前 ， 更换核心银行系统会耗费巨额资金 ， 往往无法在短期内实现投资回报 。全面置换可能需要多年的努力和巨大的资源投入 。 由于系统转换较为复杂而且日常运营可能中断 ， 更换系统还存在相当大的运营风险 。 此外 ， 系统现代化一直以来还面临一个障碍 ： 大多数传统系统可能仍足以运行核心操作 。 因此 ， 也难怪绝大多数银行选择保留传统的核心系统 ， 继续忍受传统核心系统的限制 ，而非构建独立的应用程序或利用手动流程来弥补不足 。2经历了二十一世纪初的全球性事件和2008年金融危机后 ， 银行面临大量的合规和报告要求 ， 而现在大多数大型银行不再受合规负担所拖累 。3过去十多年来 ， 为应对监管要求 ， 银行将大部分的预算和资源用于合规 。 但如今 ， 随着监管合规的实现 ， 银行可以调动更多资金重点投入以增长为中心的转型 ， 从而提升其数字化能力 。这种对核心系统置之不理的做法已不可取 。 如今 ， 许多银行都面临着难题 ： 核心系统维护和支持合同到期 ， 东拼西凑的系统定制和集成记录不全 、 难以拆解 ， 以及熟悉COBOL语言和主机系统等传统技术的人才日益稀缺而昂贵 。 鉴于大多数传统系统的高度定制化 ， 升级系统最终可能无异于构建一个全新的系统 。变革性因素纷至沓来 ， 可供支配的资金已然到位 ， 现代化产品取得进展 ， 以及意图维持现状的主张有所减弱 银行核心系统现代化势在必行 。传统系统的困境 4数字化时代下的核心银行转型核心银行系统作为银行的核心系统 ， 构成银行系统整体架构中最关键的组成部分之一 。 这些核心系统的任何变化都会对渠道和运营产生影响 。 以前 ， 全面更换核心系统是系统升级的唯一方法 ， 这使升级核心银行系统成为一个 “ 孤注一掷 ” 的决定 。庆幸的是 ， 由于支持各种解决方案的核心银行业务技术取得巨大进步 ， 银行核心系统的现代化不再是二选一的抉择 ：坐视不理或完全置换 。 新兴供应商开始提供下一代以云计算为基础 、 由配置驱动的解决方案 ， 为银行的现代化提供另一条不甚颠覆的路径 。 借助下一代系统 ， 银行可以继续利用传统系统实现大多数核心银行业务功能 ， 同时能够进行创新并应对当前最迫切的需求 。 传统供应商也在不断创新 ， 为银行通过特定的下一代功能来扩充现有系统提供更多选择 。核心银行系统可分为三大类 ：传统系统： 这类系统属于专有或封闭平台 ， 通常是主机系统 ， 提供 “ 一站式 ” 解决方案 。 其运行较为复杂 ， 通常采用以多年许可为基础的模式 。服务导向平台： 这类平台提供以服务导向架构 （ SOA） 为基础的设计 ， 并且支持实时处理 。 它们通常被视为托管软件即服务 （ SaaS） 解决方案 ， 采用许可和订阅模式 。云原生平台： 这类平台利用基于微服务的架构 ， 通过应用程序编程接口（ API） 接入其他内部和外部服务 。它们支持实时处理 ， 具备云原生的本质 ， 通常采用计次付费的订阅模式 。随着上述技术解决方案纷纷问世 ， 银行现在可通过一系列方案转变其核心系统功能 。 为确定最佳方案 ， 银行需要根据现有系统的可持续性以及自身的风险偏好 、 产品和服务革新需求 、 转型紧迫性和数据策略复杂性 （ 包括在安全 、 隐私 、 控制 、 业务连续性和风险管理 、 基础设施 、 数据变现能力等方面对现行数据策略的潜在影响 ）， 全面掌握自身在现代化方面的状况 。完善的数据管理策略至关重要 ， 有助于银行根据核心系统现代化或数字化转型探索 ， 顺利完成一次性数据迁移以及未来持续推进的数据集成 当多条业务线 、 渠道和产品线存在明显重叠且数据质量水平各异时 ， 这一策略的重要性尤为突出 。 无论偏好哪种方案 ， 银行都必须了解自身现状以及所设想的数据资产内部流动路线图 。 就运营效率和准确性而言 ， 有效管理数据非常必要 ； 银行渴求最大化收益就必须考虑丰富客户体验 、 优化交叉销售机会以及开创其他外部变现收益流等因素 ， 而有效数据管理在此方面为银行创造了机遇 。 此外 ， 明确的数据策略将赋能银行为其现有的IT环境添加高级分析功能 ， 助力银行把握实时洞察以推动制定最佳决策 。 下面和图1列示了银行需要考虑的五大方案 ：观望（不作为）： 在短期内保留现有系统及其当前功能 ， 同时跟随市场领导者确定下一步升级举措 。 此方案适用于拥有可持续的系统但可能不具备核心系统转型相关风险预测或业务案例的银行 。升级： 实施代码迁移 ， 对现有系统进行小幅升级 （ 如版本升级 ）， 但很少涉及对应用程序功能或技术的变更 。此方案可最大限度减小变更的破坏性 ， 为未来推进更有力的变革开辟道路 ， 但其本身并不能满足市场和业务需求 。重构： 在不改变基准行为的前提下 ，推进核心银行业务系统的现代化 ， 确保其代码库采用当前技术 （ 例如 ， 从COBOL转变为Java ）。 这有助于提高系统代码库的可读性 、 可维护性和可扩展性 ， 并可能实现现有核心系统的云就绪性 。增强： 部署一个并行的核心系统 ， 以满足传统核心系统无法应对的高级需求 。 新的核心系统可运行一系列差异化服务 ， 并/或作为传统核心系统数据迁移的目标 。 对于寻求维持现有产品和服务并实现快速转型的银行 ， 此方案提供了创新的解决方案 。替换： 以新的现代化解决方案替换现有核心系统 。 此方案适用于愿意付出较高初期投资且能充分论证所涉风险的银行 ， 有助于加快银行推出新产品的进程 。您不必再孤注一掷 5数字化时代下的核心银行转型图1 ：新方案已然出现，银行可视自身情况选择路径如果能更好地掌控实现核心系统现代化的方式 ， 银行无疑能够抢占优势 。 但同时 ， 确定哪种路径最行得通可能会很复杂 。 这取决于现有供应商关系和核心系统的能力 ， 以及银行的整体业务战略 、 风险偏好以及具体的变革驱动因素 。银行可选用的方案观望（不作为）升级 重构* 增强 替换 保留现有系统及其当前功能 实施小幅升级 ， 将代码迁移至升级后的系统 （ 如版本升级 ）； 不会改变应用程序的功能 ， 或无需具备重要的新技能 在不改变基准行为的前提下更新代码库 提高可读性 、 可维护性和可扩展性 ，并可能实现云就绪 部署一个并行的核心系统 ， 以满足传统核心系统无法应对的高级需求 新的核心系统可运行差异化业务 ， 并/或作为传统核心系统数据迁移的目标 以新的/现代化解决方案替换现有核心系统 助力愿意付出较高初期投资的银行加快推出新产品的进程银行状况现有系统的可持续性风险规避创新/增长目标转型紧迫性数据策略的复杂性案例/典型指标 未作出任何 “ 突破性改变 ” 根据市场选择路径 未作出任何 “ 突破性改变 ”， 但现行版本的支持合同可能即将到期 仅投资于数据库/版本更新和小幅改进 银行树立了现代化的愿景 ， 却不愿作出改变 分两步走的历程 ： 将传统代码库重构为现代化代码库 （ 例如 ， 从COBOL转换为Java） 实现现代化 ， 增强系统功能 新核心系统有着不同的业务用途 ： 数字化银行 /品牌 储蓄平台 系统实现稳定并经检验后 ， 可将传统系统的数据更多地迁移到新核心系统 传统核心系统无法满足财务 、 运营和/或业务需求 合同即将到期 将替换作为最后的手段新方案已然出现 ， 银行可视自身情况选择路径*代码重构是指在不改变外部行为的前提下 ， 对现有代码进行重构 ， 以改善非功能性技术性能 。传统核心系统新的核心系统6数字化时代下的核心银行转型哪种路径才是合适的 ？要在替换 、 增强 、 重构或升级核心系统之间作出抉择颇为复杂 。 每家银行的情况都各不相同 ， 所以不适合一刀切 。 确切而言 ， 银行需要深入分析当前的基础设施 、市场动态 、 客户需求和组织能力 。我们的方法是基于一系列关键决策点来作出明智的决策 （ 见图2 ）。 通过思考和回应这些决策点 ， 银行可以平衡风险 、 业务驱动因素和现有系统功能 ， 全面了解哪种方案最为合适 。图2 ：基于一系列决策选择升级方式您位于此处低低低低业务驱动的变革需求无作为现代化 替换替换重构增强增强升级增强或 现代化或 替换创新驱动的变革需求风险预测驱动的变革需求高高高高7数字化时代下的核心银行转型保留传统核心系统的案例（不作为 观望）我们的第一步工作是调查业务需求并确定传统系统能否满足处理要求 、 产品功能和法律合规性 。 如果银行系统的表现尚可接受 ， 银行可能会决定在短期内采取 “ 不作为 ” 的方案 。 但如果传统系统未能成功执行运营任务 ， 银行需对其进行某种形式的现代化 。尽管 “ 不作为 ” 会流露出消极意味 ， 但对于一家倾向于规避风险 、 尚无任何经验或业务案例的银行而言 ， 这或许是可取的方案 。 确切而言 ， 银行可能会期望竞争对手迈出第一步 ， 等到市场上出现一些成功案例后再采取行动 。 事实上 ，这种观望的策略可能对银行有益 ， 但银行要密切关注市场动态并着手准备迎接即将到来的变化 ， 即 ： 制定并实施提高运营效率的举措 ， 提升员工技能和招聘新员工 ， 更新业务战略并制定相应的产品和服务路线图 ， 以及与现有和新供应商建立业务关系以了解未来的选择 。 在这种情况下 ， 假设当前的方法能够满足数据需求 ， 银行将能采用相对简单明确的数据策略 。案例分析：经过评估，某区域银行决定不实施核心系统的现代化某区域银行计划将系统升级为由技术驱动的核心系统，并进行了评估，但由于能力、成本和变革管理方面的考量最终选择不进行升级。某区域性银行现有核心系统已经过时 ， 系统相关的合同即将到期 ， 因此 ， 该银行评估了其关注的问题和推进现代化的必要性 。现有核心系统的问题包括 ： 在产品和服务增加的情况下能否实现扩展 ； 与当前供应商签订合同的成本高 。采取“观望”方案该银行最终决定不实施现代化 ， 原因如下 ： 当前系统具备日常运营所需的功能 ； 该银行开展了其他几个项目 ， 这些项目仍在进行中 ， 耗费大量成本 ， 造成资源紧张 ； 该银行正在开发自己的数据仓库 ， 并希望其与新的核心系统无缝集成 ， 但事实证明困难重重 ； 核心系统现代化的变革管理非常繁琐复杂 。面对优先事项的冲突和资源上的限制，该银行只能暂缓推进核心系统现代化。8数字化时代下的核心银行转型升级或重构核心系统的案例一旦建立了针对某种变革的业务案例 ，银行就必须考虑在现有产品和能力之外进行创新的必要性 。 市场力量是否在推动银行开发数字化产品 ？ 该银行的竞争对手是否在抢先推出新产品和新服务 ？如果不是迫切需要创新 ， 银行可以根据其他必要变革的规模 ， 选择通过升级或重构来实现系统的现代化 。 两种方案详细介绍如下 ：升级： 这是两种方案中较温和的一种 。它仅作较小的调整 ， 不会改变核心系统的功能 ， 部署起来也不需要大量的新技能 。 升级核心系统的例子包括版本升级或数据库更新 。 在这种情况下 ， 数据策略的复杂度较低 。重构： 此方案意味着在不改变基准行为的前提下更新代码库 ， 有助于提高可读性 、 易维护性和可扩展性 ， 并可能在更多复杂数据需求下实现云就绪性 。就这两种方案而言 ， 虽然现代化推动银行从传统技术转向新一代技术 ， 但其本身的业务能力并没有改变 。 银行如果迫切需要提高自身业务能力 ， 比如建立新账户或客户结构 、 开发创新产品或应用先进的定价方案 ， 则需考虑增强或替换核心系统 。案例研究：瑞士某银行通过代码重构实现核心应用程序的现代化瑞士某银行采用核心系统重构战略，在6个月内实现关键业务投资系统的现代化。瑞士某私人银行需要将其关键业务投资系统从旧系统升级为现代化的新系统 。 旧系统语言不仅维护起来困难重重 、 成本高昂 ，而且很难与现代化技术接轨 。 该银行正在寻求实现旧系统的现代化 ， 同时尽量减少对持续业务运营的干扰 。对旧系统代码进行重构解决方案： 该银行实施了为期6个月的解决方案 ， 对所有的旧系统代码进行重构 ， 并将旧系统迁移至由美国某跨国技术提供商提供的新系统 跨职能 、 可移植的软件语言 。 所有的旧系统代码均以新语言进行重构 ， 所有的旧系统软件均可依照简单明确的数据策略停止工作 。获益： 重构后的应用程序保留了所有系统功能 ， 帮助银行实现显著的效率提升和成本节约 ， 包括能够满足高可用性标准 ， 以及不需要额外的用户培训成本 。 此外 ， 借助现代化的系统 ， 银行可以更轻松地与未来技术接轨 。利用现代化的软件语言重构老旧的核心系统，助力银行实现显著的效率提升和成本节约。9数字化时代下的核心银行转型增强旧核心系统的案例设想一下 ， 某银行希望推出新业务模式（ 例如 ， 新业务线或纯数字化品牌 ），而这些模型在某种程度上与现有业务不挂钩 。 在这种情况下 ， 银行迫切需要创新和机遇 ， 力求在不影响传统业务的前提下采取更具变革性的举措 。 因此 ， 银行可以把眼光放长远 ， 而不仅仅是着手推进核心系统的现代化 。 无论选择增强还是替换 ， 都会面临风险和时间问题 。随着技术的进步 ， 替换系统的风险相比十年前有所降低 ， 但对整个旧系统进行全面革新仍然非常复杂 ， 在系统替代期间业务运营可能受到干扰 。 面对核心业务职能可能在数年内遭受冲击 ， 银行获取洞察 、 做出调整 、 承担风险的能力和意愿将在很大程度上影响其在增强和替换核心系统之间的抉择 。风险偏好较低的银行考虑到所需时间和投资等因素 ， 可能会意识到通过新增新一代核心系统来增强现有核心系统的价值 。 新核心系统专门用于提供旧核心系统无法实现的新功能 ， 通常以开放 、 可伸缩和可扩展的云原生应用程序为基础 。在许多情况下 ， 银行还必须评估其数据策略 ， 而这些数据策略将会更为复杂 。如前所述 ， 增强核心系统可为未来提供多种选择 。 新的核心系统可用于一条单独的业务线或整个新的银行业务机构 。它也可以用作发布新产品和服务的试验台 ， 一旦新核心系统达到稳定状态 ， 就可逐渐将传统业务迁移至新系统 。案例分析：美国某投资银行采用新一代系统作为新的数字化手段美国某跨国投资银行通过数字化银行增强现有系统，从而进入零售银行业务市场。通过云原生产品增强核心系统解决方案： 该银行决定利用由一家印度公司开发的解决方案 预配置的 、完全基于云计算的通用银行系统解决方案 。 该解决方案确保数字渠道的直通式处理和自助服务能力 。获益： 该系统满足了产品高度灵活化和个性化的需求 ， 例如 ， 在存储和处理合同时能够选择还款条件和期限 。 该解决方案解决了时间紧迫的问题 。 这个 “ 开箱即用 ” 的预配置系统符合州和联邦银行业合规要求 ， 因而整个项目仅需8个月即可部署完成 。银行选择“开箱即用”的解决方案。该解决方案部署时间短、符合合规要求且个性化设置方便，帮助银行增强当前系统。10数字化时代下的核心银行转型完全替换核心系统的案例最后一种方案又把我们带回到老问题上 。 如果摸索不出可行的升级路径来实现业务目标 ， 银行仍然可以选择替换整个旧系统 。 这种 “ 赌上一切 ” 的方法虽然充满风险 ， 但如果现有的系统无法再继续使用 ， 就仍可能具有吸引力 。 此外 ， 银行还必须考虑数据方面的各种复杂因素 ， 比如将数据从旧系统迁移到所选择新系统的策略 。 这种方法需要专注重点 、 眼光长远 ， 才可能比采用相对较慢 、 风险较小的方法的竞争者更具竞争优势 。案例分析：以色列某银行用数字化银行业务解决方案替换老旧的核心系统一家总部位于以色列的全球性银行用新一代数字化系统替换核心银行业务系统，以此实现与客户的实时互动并增强财务能力。根据战略重点 ， 该银行希望推出数字化银行产品 ， 以满足客户和市场需求 。 其现有的核心系统建立在多个已过时的复杂系统之上 ， 无法提供数字化银行产品和服务 ， 而且为满足日常运营所需而进行维护的难度和成本日益增加 。以数字化解决方案替换旧的核心系统解决方案： 该银行决定用端到端的数字化银行业务解决方案替换其核心系统 ， 该解决方案来自新一代供应商 ， 以云计算为基础 ， 具备云原生性质 ， 而且可实现实时处理 。 供应商的解决方案非常灵活 ， 所提供的部署期限和成本结构具有竞争力 。获益： 能够提供创新产品 ， 例如 ： 全天候数字化银行业务 、 使用移动应用功能进行身份验证以及光学字符识别 （ OCR） 技术 。 每年节省数百万美元的IT维护费用 。 确保银行能够提供数字化产品 ， 以正面回击蚕食其市场份额的金融科技公司 。某领先的以色列银行采用灵活、成本效益高的数字化银行业务解决方案替换过时的核心银行业务系统，实现向数字化银行的迈进。