Digital twins in banking
Digital twins in banking are digital models of financial activities that are updated with observations from the activities they represent. A bank can use the model to examine possible changes before making decisions about the real process. The usefulness of a banking digital twin depends on the quality of its data and the assumptions connecting that data to outcomes.
A digital twin has a defined scope, such as a banking product or a payment process, and a specified update frequency. Simulation allows a team to change selected assumptions and compare possible outcomes within that scope. A static process diagram can provide a starting point, but a maintained model also needs data updates and tested behavior.
Define the banking decision first
A banking digital twin should support a decision that the responsible team can define precisely. For example, a payment operations team might examine how delayed incoming payments would affect settlement queues during a particular operating period. The model boundary should identify the participating accounts and the settlement rules included in that question. Activities outside that boundary remain explicit assumptions, so a result for one payment process cannot establish the behavior of the entire bank.
Financial planning and funding at Atom bank
Durham University and Atom bank developed a banking digital twin using mathematical and statistical models of the relationships between customers and products. The historical project supported decisions about financial planning, product pricing and funding, with model updates using actual data as products matured. Banks assessing a similar approach should specify which business decisions their own model must support and how actual results will test its assumptions.
Payment flows and intraday liquidity
The Bank of Finland payment and settlement system simulator supports liquidity analysis and settlement performance assessments, including evaluations of changed rules and stress scenarios. These capabilities give banking teams concrete examples of questions that financial simulation can address. A simulator becomes part of a digital twin when a defined update process maintains the relationship with the financial activity modeled. For intraday liquidity, teams should compare settlement delays and required liquidity under the same stated payment assumptions.
System dependencies before a banking change
A banking process can depend on several applications and on rules applied between those applications. A digital twin can model the relevant dependencies and test how a proposed change affects the process under defined conditions. The model needs evidence connecting system events to the business outcomes being measured, including any manual processing steps. Legacy modernization in banking addresses the implementation of system changes, while the digital twin provides a maintained environment for examining selected consequences before and after those changes.
Data updates and model boundaries
Every input to a banking digital twin needs an identifiable origin and a recorded observation time. The team should specify how often inputs are refreshed and what happens when a source becomes unavailable or outdated. Aggregated or synthetic records can support particular tests, but their limitations must remain visible when interpreting results. Access permissions and data retention need their own controls, while reconciliation checks should show whether balances and payment totals remain consistent with the defined financial scope.
AI support for understanding existing systems
AI coding agents in finance can help teams investigate existing code and propose explanations of dependencies between applications. Those explanations can inform a banking digital twin after technical specialists verify the relevant business rules against code and observed behavior. A generated description alone does not establish the numerical behavior of a payment or funding model. Financial calculations need reproducible methods and checked inputs, with a named reviewer responsible for accepting changes to the model and its assumptions.
Risk scenarios and validation
The ongoing BIS Project Danu is developing a digital twin framework for monitoring emerging financial stability risks, including risks from natural catastrophes and extreme weather. The project combines data monitoring with scenario simulation and continuous data ingestion as part of its planned framework. At bank level, model validation should compare simulated outcomes with observed results and examine sensitivity to uncertain assumptions. A scenario is an analytical result within a model boundary, with uncertainty that decision makers need to understand.
Begin with one measurable financial process
A first banking digital twin can focus on a bounded payment flow with an existing operational owner. Before development starts, the team should agree on the decision supported and the evidence needed to accept the model. Historical replay can test whether the model reproduces known behavior before teams evaluate changed conditions. Continuing use then requires an update schedule and a review after relevant process changes, so the relationship between the digital model and the financial activity remains inspectable over time.
Banking processes and financial models
Digital twins in banking and Finance Loop
Finance Loop connects professionals working on emerging technologies across European financial services, with Central Europe as the current regional focus. Banking specialists and technology providers can discuss the experience needed to assess financial models and their operational use.
Finance Loop is a professional network for relationships and exchange across cities and countries. Organizations can contact Finance Loop about relevant professional introductions and describe the banking process they want to explore.