Capital Twin, SAP-RPT and the Missing Link Between Artificial Intelligence, Corporate Banking and Real-World Business Processes

Why Predictive AI Cannot Replace Business Architecture — and Why the Future of Banking Requires Both 1. The Fundamental Misunderstanding About Artificial Intelligence in Enterprise Systems One of the most persistent misconceptions in the current discussion about artificial intelligence is the belief that implementing an advanced AI model is, in itself, sufficient to automate complex business activities. The assumption is relatively simple: an organization has a process currently performed by people, it implements an AI model, and the model replaces those people. Unfortunately, this is not how enterprise automation works, particularly in complex industrial, commercial and financial environments. There is an essential intermediate step that is frequently overlooked: the underlying business process must first be understood, modelled, structured and implemented in the operational systems responsible for executing it. This distinction is particularly important when discussing SAP's artificial intelligence technology, and especially its Relational Pre-trained Transformer (SAP-RPT). SAP has a considerable structural advantage in this respect. Its enterprise software has been developed over decades around highly structured business objects, transactions, relationships and processes. These represent patterns of economic activity that are repeated across thousands of companies and industries. Purchase orders, sales orders, contracts, deliveries, inventory movements, invoices, payments, accounting entries and financial positions are not simply isolated records. They are representations of activities that follow identifiable business rules and relationships. Over several decades, SAP has progressively incorporated increasingly sophisticated capabilities to model, execute and automate those activities. However, there is an important distinction between a functionality existing in the SAP software and a customer actually having that functionality implemented and configured. An organization may have access to sophisticated automation capabilities while continuing to perform many of the associated activities manually. The functionality exists. The business logic may even be known by the employees responsible for executing the process. But the logic has not necessarily been translated into a configured system capability. This is precisely where artificial intelligence becomes relevant. The purpose of predictive AI should not be understood as simply replacing an employee with an algorithm. Its greater potential is to introduce dynamic intelligence into business processes that have already been structurally modelled and implemented. And this distinction is fundamental to understanding both the strategic importance of SAP-RPT and the architecture we are developing with Capital Twin. 2. SAP-RPT: Intelligence Applied to Structured Business Reality SAP's Relational Pre-trained Transformer is particularly interesting because it approaches artificial intelligence from a different direction than conventional Large Language Models. SAP-RPT is a relational foundation model designed for structured and tabular business data. It works with relationships between records, rows and columns and supports predictive tasks such as classification and regression through in-context learning. Unlike an LLM, whose principal interaction with information takes place through natural-language sequences, SAP-RPT is designed to work directly with the structured data that characterizes enterprise systems. This is an important architectural distinction. Enterprise business information is not fundamentally a collection of paragraphs. It consists of objects, attributes, relationships, conditions, events and numerical values. For example, a business transaction may depend on the relationship between a customer, a product, a contractual agreement, a geographical location, an inventory position, a delivery commitment and a series of operational constraints. These relationships are already represented, to varying degrees of standardization and configuration, in enterprise applications. SAP-RPT can identify patterns in structured business data and predict missing or future values. SAP documents classification and regression as its supported prediction tasks, with predictions generated using examples supplied as context rather than requiring a separate conventional training cycle for every individual task. This makes it particularly relevant to enterprise environments where the objective is to extract predictive intelligence from existing business information. However, we should be precise about what this means. SAP-RPT does not automatically understand an entire business process in the sense of independently designing its operational model, configuring SAP functionality and implementing every decision rule. Nor does it automatically generate a complete business architecture. Its role is predictive. The architecture surrounding it must determine which business question needs to be answered, which data is relevant, which variables should be predicted, what the resulting predictions mean operationally and how those predictions should influence the execution of the process. In other words, the intelligence must be connected to an existing business model. This is not a limitation of SAP-RPT. It is a necessary architectural separation between predictive intelligence and business-process execution. 3. A Practical Example: The Delivering Plant in an SAP Sales Order Let me illustrate this with a concrete example from SAP Sales and Distribution. I suspect that many SAP professionals will immediately recognize the importance of the delivering plant at sales-order item level. When a customer places an order for a particular product, the company must determine which plant will supply that product. This is not necessarily a trivial decision. A company may have several plants capable of supplying the same customer, depending on the material, the sales organization, the distribution channel, geographical considerations, inventory availability, transportation arrangements and other business conditions. In earlier SAP implementations, this determination could rely heavily on manual selection, with relatively simple default-determination mechanisms. The user might have several potentially suitable plants available and would select the most appropriate one. A default plant could be proposed automatically. However, if that plant did not have sufficient inventory, if transportation from another location was more advantageous, or if some other commercial or operational consideration applied, the user could change the proposed plant. The employee was effectively executing a business decision using information and rules that were not necessarily represented in the SAP system. Some of those rules might have been documented in an Excel spreadsheet. Others might have existed only in the employee's experience or knowledge. For example: Supply from the nearest plant whenever sufficient stock is available. Prefer a particular plant when transportation costs are significantly lower. Avoid using certain routes under specific conditions. Give priority to particular plants for customers with specific contractual arrangements. Consider whether the customer orders complete pallets or partial pallets. Take account of the available dispatching capacity at each location. Consider the expected delivery date and transportation constraints. The employee was effectively applying a decision model. The problem was that much of that model remained outside the enterprise software. This is a fundamental obstacle to automation. An e-commerce customer cannot reasonably be expected to understand the supplier's internal distribution network and determine which warehouse should fulfil an order. Imagine placing an order on Amazon and being asked whether your purchase should be supplied from the New York distribution centre or the Pittsburgh distribution centre. The customer neither has the information nor should have the responsibility to make that decision. The company must make it automatically. And to do so reliably, it must have implemented the business logic that governs the decision. 4. From Manual Decisions to Rule-Based ATP: SAP APO Global ATP SAP progressively addressed this type of problem through increasingly sophisticated availability-checking capabilities. An important development was Rule-Based ATP within Global Available-to-Promise in SAP Advanced Planning and Optimization (SAP APO). Rule-Based ATP made it possible to translate business rules used in supply and availability decisions into configurable system logic. This was a substantial conceptual advance. Instead of depending on an employee to remember the conditions under which one plant should be preferred over another, the organization could model those conditions within SAP. The rules could include different combinations of business attributes and constraints. The system could evaluate the relevant conditions and determine which alternative locations or products were appropriate for the availability check. The important point is that the organization was not inventing a new decision every time a sales order was created. It was formalizing a decision model that already existed, explicitly or implicitly, within the business. SAP's APO documentation describes the configuration of the rules-based availability check through condition techniques and integrated rule maintenance. This is precisely the architectural principle I want to emphasize. The first step towards automation is not artificial intelligence. It is the formalization and implementation of business knowledge. However, there is another important consideration. Many SAP customers never implemented these advanced capabilities. They continued using simpler configurations, manual intervention or business rules maintained outside the system. Consequently, a considerable amount of operational knowledge remained disconnected from the actual execution capabilities of their SAP environments. Even when the technology was available, the organization had not completed the necessary implementation work. This is still a relevant problem today. 5. Advanced ATP: The Evolution of the Operational Decision Model SAP subsequently developed the S/4HANA generation of advanced availability-management capabilities, known as Advanced Available-to-Promise (aATP). Advanced ATP provides a more modern set of capabilities for managing product availability and order confirmation within S/4HANA. Among its capabilities are Product Availability Check, Product Allocation, Backorder Processing, Supply Protection and Alternative-Based Confirmation. Alternative-Based Confirmation is particularly relevant to the example discussed above. When the originally requested plant cannot satisfy a sales-order requirement appropriately, aATP can evaluate alternative delivering plants, storage locations or products. Depending on the configuration, the system can identify and evaluate alternative confirmations, using defined criteria, constraints and heuristic approaches. SAP also provides configuration capabilities for defining alternative determinations based on rating attributes and hard constraints. The underlying principle remains recognizable: business conditions must be represented in the system before the system can execute the decision. It is important to distinguish the evolution of these capabilities from a strict one-to-one replacement of every historical APO Global ATP function. The architectures and individual functions differ, and the relevant migration scope must be evaluated for each implementation. Nevertheless, the broader evolution is clear. SAP has progressively provided more sophisticated mechanisms for translating operational knowledge into executable business logic. And this is precisely the kind of environment in which predictive AI becomes strategically valuable. 6. The Missing Dimension: Making Business Rules Dynamic Now consider the limitations of a conventional rule-based approach. Suppose a company has configured its sourcing rules perfectly. It knows which plants can supply which products, which transportation routes are available, what the contractual restrictions are and how different commercial priorities should be evaluated. The problem is that the business environment does not remain constant. A sourcing rule that was optimal six months ago might no longer be optimal today. Transportation costs change. Fuel prices fluctuate. Traffic conditions vary. Customer demand changes. Warehouses acquire additional capacity. New production lines become operational. A particular distribution centre might be operating below capacity, while another is approaching its limits. The rules need to adapt. Consider a practical example. A distribution centre originally has a certain capacity to prepare and dispatch customer orders. The company subsequently installs an additional machine or introduces a second operational shift. The centre's dispatching capacity effectively doubles. This is not merely an isolated operational improvement. It has consequences throughout the supply chain. The company may now benefit from directing a greater proportion of customer orders through that distribution centre. However, doing so also means that the centre needs to receive more inventory. Consequently, procurement, replenishment, inventory positioning and transportation planning may also need to change. A decision at the sales-order sourcing level can therefore have downstream consequences across multiple operational processes. Traditionally, a supply-chain director or planning specialist might periodically review an Excel spreadsheet containing the relevant business parameters. That person would update the sourcing priorities and communicate the changes to the teams responsible for inventory planning and operational execution. This is another human activity that could potentially be made more intelligent and responsive. And this is where SAP-RPT becomes particularly interesting. Instead of treating the business rules as entirely static, we can use predictive intelligence to help determine how their parameters should evolve as the economic and operational environment changes. For example, structured information about: Transportation costs. Fuel prices. Route characteristics. Derived traffic indicators. Historical delivery performance. Plant dispatching capacity. Inventory availability. Customer demand. Operational restrictions. Delivery commitments. could be brought together to support predictive analysis. Where these variables are represented as suitable structured inputs, SAP-RPT can be used to predict relevant numerical values or classifications. For instance, it could contribute to predicting an estimated delivery-delay category, a relative cost indicator or a parameter that influences the priority assigned to a particular sourcing alternative. The important qualification is that external information, including geographical or traffic information, must first be transformed into appropriate structured business attributes. SAP-RPT is not itself a geographical mapping engine or a general-purpose time-series forecasting system. Its output must then be interpreted within the business model. The purpose is not to ask the AI to invent a new supply-chain architecture. The purpose is to give the existing architecture better and more dynamically informed parameters. 7. Predictive Intelligence Does Not Execute the Business Decision This is perhaps the most important distinction in the entire discussion. SAP-RPT does not need to determine the delivering plant directly. In fact, that would not necessarily be the most appropriate architectural approach. The delivering plant should be determined by the relevant operational application, such as the configured availability and alternative-confirmation mechanisms in aATP, applying the business rules, constraints and operational conditions established by the organization. SAP-RPT has a different responsibility. It can contribute the predictive information used to determine the parameters under which those rules should operate. Consider the following sequence: First: The business process and its operational constraints are modelled. Second: The sourcing rules are implemented and configured in the relevant SAP functionality. Third: Structured operational and market information is made available to the predictive model. Fourth: SAP-RPT generates predictions for the specific variables that have been defined as relevant to the business decision. Fifth: Those predictions are validated and translated into approved parameter updates. Sixth: The updated parameters are made available to the configured operational decision model. Finally: The operational application executes the decision using its established business logic. The actual sourcing decision continues to be made by the appropriate operational mechanism. The predictive model contributes the intelligence required to make the existing decision mechanism more responsive to changing circumstances. This is an important distinction between predicting a parameter and executing a business decision. It also illustrates why the implementation of SAP-RPT cannot be separated from the architectural work required to model the underlying processes. The AI is only one component of a much larger system. 8. Why This Is Particularly Important for Banking Now let us move from supply-chain management to banking. I believe that one of the biggest mistakes currently being made by many financial institutions is to treat artificial intelligence as an almost binary proposition. Either the bank implements AI, or it does not. The assumption is that once an advanced AI model has been introduced, it will somehow take responsibility for complex financial processes that previously required substantial human expertise. But banking is not a collection of isolated questions that can be answered through natural-language interaction. It is an extraordinarily complex network of contractual relationships, financial instruments, obligations, operational events, accounting consequences, risk exposures and regulatory requirements. A banking decision can depend on multiple layers of contractual and financial information. For example, determining the financial exposure associated with a particular counterparty may require an understanding of the underlying contractual relationships, outstanding obligations, available collateral, drawn and undrawn facilities, maturity structures, contractual conditions and relevant operational events. The calculation of credit-risk parameters such as Probability of Default (PD), Loss Given Default (LGD) and Exposure at Default (EAD) requires properly designed models, appropriate data and carefully defined methodologies. Similarly, the identification of an event of default is not simply a matter of asking an LLM whether a borrower appears to be in financial difficulty. There are contractual, operational, accounting and regulatory conditions that must be explicitly represented. The same applies to capital calculations, Basel requirements and the relationship between contractual obligations and financial positions. These are not problems that can be solved simply by installing an AI model. They require extensive modelling and implementation work. And this is precisely where Capital Twin becomes relevant. 9. Capital Twin: The Architectural Foundation That Must Exist Before AI Can Deliver Its Full Potential Capital Twin is based on a fundamental architectural principle: financial capital cannot be represented adequately without representing the contractual and economic reality from which that capital originates. Traditional financial representations frequently concentrate on accounting balances, positions, exposures and reporting outcomes. These are essential, but they do not necessarily provide a complete representation of the underlying contractual relationships and operational events that produce those outcomes. The Capital Twin approach is different. It seeks to establish a coherent, contract-centric representation of the financial and economic reality of the institution. This means identifying the relationships between: Contracts and their contractual conditions. Financial products and their economic characteristics. Counterparties and associated entities. Rights, obligations and payment commitments. Credit facilities and collateral arrangements. Operational events and changes in contractual status. Financial flows and accounting consequences. Risk exposures and capital implications. Regulatory classifications and reporting requirements. The objective is not simply to create another database containing banking information. It is to construct an architecture in which the relationships between these elements are explicitly modelled and can be understood, validated and executed consistently. This requires a considerable amount of functional and architectural work. And, importantly, much of that work must take place before sophisticated AI capabilities can be expected to deliver meaningful results. The analogy with Advanced ATP is particularly useful here. Just as an SAP consultant cannot expect a sophisticated availability-checking application to make intelligent sourcing decisions without correctly modelling and configuring the relevant business rules, we cannot expect an AI model to produce reliable capital and risk decisions without first designing the financial models it is supposed to support. 10. The Consulting Work Behind Capital Twin: Modelling the Financial Processes This is where I believe it is necessary to be particularly clear about the nature of the work involved in developing Capital Twin. There is a substantial difference between understanding an SAP module at a functional level and understanding the business processes and decision models that its more sophisticated capabilities implement. The difference between a consultant who understands basic Sales and Distribution configuration and a specialist who understands the architecture and configuration of Advanced ATP is a useful illustration. Both may work within the same general SAP environment, but the depth of functional knowledge required is very different. The same distinction applies to banking. A general understanding of SAP financial applications is not sufficient to design a comprehensive representation of banking capital. We need to analyse the actual business processes, identify the relevant SAP objects and relationships, understand their financial implications and translate that knowledge into explicit models. For example, consider the development of a credit-risk representation. We cannot simply tell SAP-RPT to calculate Basel exposure. We first need to establish: What constitutes the relevant contractual relationship. Which events can change the status of that relationship. Which contractual conditions determine the financial obligations. How drawn and undrawn amounts are represented. How collateral and guarantees affect the exposure. Which contractual and operational conditions are relevant to identifying an event of default. How the relevant risk methodologies determine PD, LGD and EAD. How these calculations relate to the applicable regulatory framework. How the resulting information is reconciled with the relevant accounting and financial representations. Which parameters are static, which are periodically reviewed and which can benefit from predictive adaptation. These are architectural and functional decisions. They cannot be delegated indiscriminately to a predictive AI model. The same principle applies to other banking processes, including lending, treasury, collateral management, payments, financial products and accounting. The Capital Twin development process therefore requires detailed analysis of the SAP functionality that represents these activities. Some processes are relatively straightforward. Others are extremely sophisticated and involve extensive configuration possibilities, complex relationships and dependencies across different modules and applications. It is necessary to understand that complexity, identify the relevant data structures and determine how the information must be translated into the Capital Twin's common financial representation. This is not an exercise in simply extracting data from SAP. It is an exercise in understanding the business logic embedded in the enterprise systems and representing its financial consequences coherently. 11. The Role of SAP-RPT Within Capital Twin Once these models have been properly designed and implemented, SAP-RPT can become a particularly valuable component of the Capital Twin architecture. Its role is not to design the Capital Twin's financial ontology, determine the meaning of every contractual event or independently invent the regulatory methodologies. Its role is to provide predictive intelligence where structured data supports meaningful predictions. For example, a financial institution may have established a model for representing the evolution of a particular credit exposure. That model may contain variables describing contractual conditions, payment behaviour, collateral characteristics, counterparty information and other relevant attributes. Some parameters may be determined through explicit contractual rules. Others may be defined by regulatory methodologies. Still others may be suitable for predictive estimation using historical and current structured information. This is where a model such as SAP-RPT can contribute. It could, subject to the suitability and validation of the specific prediction task, help estimate relevant numerical values or classify exposures according to defined characteristics. Those predictions could then become inputs to the appropriate financial or risk models. The same principle applies to capital optimization. A Capital Twin may represent the contractual and financial consequences of alternative business decisions. Predictive models could provide estimates of relevant parameters under different market or operational conditions. The Capital Twin's financial models could then evaluate the consequences of those parameters for exposure, risk, capital consumption and other economic variables. The objective is not to confuse prediction with calculation. Prediction supplies information about uncertain or changing variables. Deterministic financial logic and appropriately governed risk methodologies apply the defined calculations and constraints. This separation is particularly important in a regulated environment. A model-generated prediction must not automatically become a regulatory capital parameter simply because an AI system has produced it. It must first pass the appropriate methodological, validation, governance and approval processes. The architecture must distinguish between predictive estimates, approved model parameters, contractual facts and regulatory calculations. This is precisely the sort of separation that makes Capital Twin more than an AI application. It is a framework for representing and processing financial reality in a structured and controlled manner. 12. The Importance of Standardization: Why SAP Has a Structural Advantage The most important architectural opportunity behind Capital Twin is not the harmonization of banking systems. Banking systems are not harmonized. Each financial institution has its own legacy infrastructure, proprietary developments, data structures, operational processes and historical technology decisions. Every bank is responsible for its own architecture, and Capital Twin does not depend on changing that reality. The harmonization we are interested in already exists somewhere else: in the real economy. SAP has spent decades developing and progressively standardizing the way businesses represent and execute their economic activities. Across its global ecosystem, companies use a common business vocabulary and a substantial body of shared functional concepts, processes, data structures, application logic and executable functionality. Consider some fundamental examples: the concept of a plant, a sales order, a purchase order, a business partner, a material, a delivery, an invoice or a pricing condition. These are not merely common labels or equivalent database tables. They represent business concepts that SAP has progressively formalized through standardized processes, functional modules, program logic, configuration mechanisms and executable software. Of course, SAP implementations are not identical. Different companies operate different releases, modules and configurations. Some have implemented advanced functionality such as Advanced Available-to-Promise; others continue to manage corresponding decisions manually or through simpler configurations. Some have extensive industry-specific implementations, while others use a relatively limited portion of the available functionality. But this does not eliminate the underlying harmonization. The same fundamental concepts of a business partner, a sales order, a delivering plant or a pricing condition remain recognizable across these environments. The degree of functional implementation differs, but the underlying business vocabulary and the standardized mechanisms through which SAP represents economic activity provide a common foundation. Furthermore, this harmonization is not confined to data structures. It extends to processes, application code, functional components and the mechanisms through which business decisions are executed. SAP's evolution from traditional ERP functionality through the more advanced capabilities of APO, S/4HANA and its increasingly sophisticated application architecture illustrates this progression. The emergence of Clean Core principles further reinforces the direction towards standardized functionality, controlled extensibility and a greater reliance on common SAP capabilities rather than customer-specific modifications. This is also an important part of the strategic context for SAP-RPT. Its ability to work with structured enterprise data benefits from the common patterns, relationships and business semantics embedded in the SAP ecosystem. The standardization of the real economy is therefore not simply a matter of having similar database structures. It provides a substantial body of recurring business logic and structured economic information on which predictive intelligence can operate. Capital Twin exploits this existing harmonization. It does not attempt to create harmonization where it does not exist. Our task is to translate the economic reality represented and managed through SAP into the language of the capital markets established by the Basel Committee on Banking Supervision. This is the fundamental architectural transformation. On one side, we have the real economy: companies buying and selling products, manufacturing goods, managing inventory, delivering orders, entering into contractual relationships, making payments, extending commercial credit and generating economic value. On the other side, we have the financial and regulatory language through which that economic activity must be understood by capital markets and financial institutions: default, Exposure at Default (EAD), Probability of Default (PD), Loss Given Default (LGD), Risk-Weighted Assets (RWA), capital requirements and the other relevant dimensions of prudential risk representation. Capital Twin establishes the connection between these two worlds. It takes the contractual, operational and economic reality already represented in SAP and translates its relevant financial consequences into structured models expressed in the language of banking risk and capital. The objective is to standardize the representation of the capital generated by the real economy, not to standardize the internal operations of every bank. This distinction is fundamental. SAP is commonly associated with the management of approximately 75% of global GDP and 84% of international trade. These figures illustrate the extraordinary scale of the economic activity represented across its ecosystem. Our opportunity is to exploit the common business semantics and functional standardization underlying that activity and translate it into a consistent capital-market representation. This is where the concept of Financial Airbnb becomes particularly relevant. Airbnb does not require every hotel, hotel chain or accommodation provider to adopt the same internal management system. It does not attempt to harmonize their operating models, accounting systems, reservation infrastructure or organizational structures. Instead, it standardizes the representation of accommodation supply through a common platform. Different providers retain responsibility for their own operations, but their available accommodation can be represented, discovered and accessed through a common framework. Capital Twin follows an analogous principle. We standardize the representation of capital originating in the real economy, using the common business processes already formalized through SAP, and make that representation available through a banking-oriented architecture that we call Financial Airbnb. Banks do not need to share the same legacy systems, adopt identical operating models or transform their internal infrastructures to participate. Each institution remains responsible for its own technology, risk management, regulatory compliance and operational decision-making. Our architecture provides a common representation and an integration gateway through which banks can access and interact with the standardized capital supply originating in the real economy. The analogy goes further. Hotel chains can integrate their accommodation systems with Airbnb, and companies can integrate their corporate travel-planning tools with the platform to reserve accommodation for their executives. The participating organizations retain their own systems while connecting to a common representation of supply and demand. Similarly, banks will have an integration gateway into Financial Airbnb. They will be able to connect their own banking environments to a standardized representation of real-economy capital without having to adopt a common banking legacy or participate in an industry-wide banking transformation. Our responsibility is to standardize the supply of capital generated by the real economy. The banks are responsible for themselves. This is the fundamental architectural distinction behind Capital Twin. We are not trying to harmonize the banking industry. We are exploiting the harmonization that already exists in the SAP-managed real economy and translating it into the regulatory and financial language of capital markets. Instead of attempting to reconcile thousands of heterogeneous banking architectures, we start from an economic substrate in which common business concepts, processes and functional mechanisms have already been developed and standardized over several decades. We then transform that substrate into a common, contract-centric representation of capital, expressed through the concepts required by the Basel framework. The Capital Twin is an architecture for standardizing and connecting the capital of the real economy, using SAP's existing harmonization as its foundation and providing banks with a common gateway to that standardized capital supply. 13. Why the LLM-Centred Approach Is Not Enough The distinction between SAP-RPT and Large Language Models is also important when considering the future of banking automation. They can interpret unstructured information, communicate in natural language, summarize documents, assist employees and support many analytical activities. However, their probabilistic generation mechanism makes them fundamentally different from deterministic business-process execution systems. A language model may produce an apparently convincing answer that is nevertheless incorrect. In regulated banking processes, the consequences of incorrect outputs can be catastrophic. An erroneous interpretation of a contractual condition, an incorrect financial amount, a misunderstood regulatory requirement or an unjustified modification of a risk classification can create considerable operational, legal and financial consequences. The hidden costs are not limited to correcting an incorrect answer. They include coordination, control, validation, auditability, accountability and operational-risk management. 14. The Architecture We Should Be Building: From Business Knowledge to Adaptive Execution The relationship between SAP's operational functionality, SAP-RPT and Capital Twin can be understood through four distinct architectural layers. Layer 1 — Business-process and data representation The first layer identifies how the real-world activity is represented in enterprise systems. It includes business objects, contracts, events, relationships, master data, operational conditions and the relevant SAP functionality. This is where the detailed functional and architectural analysis takes place. Layer 2 — Explicit business and financial models The second layer translates that understanding into executable models. In supply-chain management, this might involve sourcing rules, availability conditions, capacity constraints and replenishment relationships. In banking, it involves contractual models, financial relationships, exposure calculations, risk methodologies, default conditions and capital representation. This layer requires domain expertise and deliberate configuration. Layer 3 — Predictive intelligence The third layer introduces AI capabilities such as SAP-RPT. The model processes appropriately structured information and produces predictions for defined variables. Those predictions can be used to update, recommend or refine parameters in the business models, subject to the relevant validation and governance requirements. The important distinction is that predictive intelligence enriches an existing model rather than replacing the need to design that model. Layer 4 — Controlled execution and feedback The final layer executes the resulting decisions through the appropriate operational applications and financial calculation mechanisms. The results are monitored, compared with expectations and used to improve the predictive context and the approved decision parameters. The entire process becomes a continuous cycle of modelling, prediction, validation and execution. This is the architecture that allows AI to become genuinely useful in complex enterprise environments. 15. Capital Twin Is Not a Shortcut Around Architecture. It Is the Architecture. I want to emphasize one final point because it has direct implications for the way we approach the development of Capital Twin. There is a considerable amount of consulting, functional analysis and architectural design involved in this initiative. We need to understand SAP's existing banking functionality, identify which processes are already standardized, determine which capabilities are actually implemented in customer environments and establish how the relevant information should be represented in Capital Twin. We also need to design the financial and risk models that connect those processes with the representation of capital. This includes the detailed mapping of contractual relationships, financial events, exposure calculations, default conditions and the relevant regulatory methodologies. Only after that work has been completed to the necessary level of detail can we determine where predictive AI adds value, which parameters it should estimate and how its outputs should be incorporated into the architecture. This work is not a secondary activity that can be postponed until after the implementation of an AI model. It is a prerequisite for obtaining reliable results from AI in complex financial processes. The distinction is similar to the one between a basic SAP consultant who manually handles a process and an architect who understands how the underlying business rules can be implemented through advanced system functionality. The latter does not simply know how to operate the software. The latter understands how the business activity must be represented so that the software can execute it reliably. That is the level of understanding required for Capital Twin. 16. The Real Opportunity: Combining SAP's Standardized Business Knowledge with Adaptive Financial Intelligence The strategic opportunity is therefore considerably broader than introducing artificial intelligence into banking. SAP has spent decades building the operational language through which a substantial part of the global economy represents its business activities. Its applications contain highly developed mechanisms for representing commercial, logistical, financial and operational processes. SAP-RPT introduces a new predictive capability that can extract intelligence from the structured information associated with those processes. But neither the existence of the SAP functionality nor the availability of predictive AI guarantees that a customer will achieve automation. The relevant business capabilities must still be understood, configured, connected and governed. Capital Twin extends this principle into the representation of banking capital. It provides a framework for connecting contractual and economic reality with the financial and risk models that determine the institution's exposures and capital implications. It also establishes the architectural foundation on which predictive intelligence can be applied without confusing probabilistic predictions with contractual facts or deterministic financial calculations. The result is a different way of thinking about banking transformation. Instead of expecting an AI model to independently understand and automate an extraordinarily complex financial institution, we first establish a coherent representation of its underlying financial reality. We then use predictive intelligence to make the resulting models more adaptive. And finally, we execute decisions through properly configured and governed mechanisms. The implementation work is substantial, but it is fundamentally different from attempting to redesign and transform every individual banking process and system from within. The common architectural foundation creates the possibility of reusing knowledge and models across institutions, while accommodating the specific configurations and requirements of each bank. This is where I believe the greatest strategic value of Capital Twin lies. Conclusion: The Future Is Not AI Replacing Business Models. It Is AI Making Them Intelligent. The evolution of SAP's ATP capabilities provides a very useful illustration of how enterprise automation actually develops. First, a business activity is understood. Then, the knowledge previously held by employees is formalized into rules. Those rules are implemented in the appropriate application. Finally, predictive intelligence can make the parameters of the decision model more responsive to changing market and operational conditions. The same principle applies to banking, although the contractual, financial and regulatory complexity is considerably greater. We should not expect SAP-RPT, or any other AI model, to design the financial architecture, understand every contractual relationship, invent Basel methodologies and independently configure an entire banking institution. That is not the problem AI needs to solve. The problem we need to solve is how to represent financial reality properly, establish the models that explain it and introduce predictive intelligence into those models in a controlled and reliable manner. This is precisely the purpose of Capital Twin. Capital Twin is not about asking artificial intelligence to replace banking knowledge. It is about transforming that knowledge into an explicit, structured and reusable architecture that artificial intelligence can make increasingly intelligent. The next financial revolution will not come from simply deploying more powerful AI models. It will come from building the architecture that allows those models to understand, predict and optimize financial reality. Technical references SAP Learning — Introducing the SAP-RPT Model SAP Help Portal — SAP-RPT-1 SAP Help Portal — Settings for the Rules-Based Availability Check (SAP APO) SAP Help Portal — Alternative-Based Confirmation in aATP SAP Help Portal — Configure Alternative Determination Connect and Stay Informed: Join the Conversation: Connect with fellow professionals in the SAP Banking Group on LinkedIn. https://www.linkedin.com/groups/92860/ Stay Updated: Subscribe to the SAP Banking Newsletter for the latest insights. https://www.linkedin.com/newsletters/sap-banking-6893665983048081409/ Join my readers on Medium where I explore Capital Optimization in depth. Follow for actionable insights and fresh perspectives https://medium.com/@ferran.frances Explore More: Visit the SAP Banking Blog for in-depth articles and analyses. https://sapbank.blogspot.com/ Connect Personally: Feel free to send a LinkedIn invitation; I'm always open to connecting with like-minded individuals. ferran.frances@gmail.com I look forward to hearing your perspectives. Kindest Regards, Ferran Frances-Gil. #SAPRPT #SAPPay #SAPBN4L #ContractualGravity #CapitalTwin #SAP #CapitalOptimization #PredictiveFinance #SAPIFRA #AutonomousEnterprise #FerranFrances

The BIS Has Mapped the Future of Banking. The SAP Capital Twin Connects All Five Core Banking Functions to Economic Reality.

Introduction: Banking Is Not Disappearing. Its Economic Architecture Is Being Reconfigured. The Bank for International Settlements (BIS), often described as the central bank for central banks, has published a particularly important study: Scenarios for Future Banking: Implications for Profitability, Liquidity and Solvency, BIS Working Paper No. 1391, November 2026. Authored by Christian Schmieder, Renzo Corrias and Oliver Wünsch, the report examines how technology, regulation, consumer preferences and macro-financial conditions could transform the banking industry over the next decade. Its research covers approximately 9,000 banks across more than 150 jurisdictions. Rather than predicting the disappearance of traditional banking, the authors investigate a much more consequential question: who will perform the different economic functions traditionally performed by banks, who will own the customer relationships, who will generate the revenue, and who will ultimately retain the financial risks? The conclusions deserve serious attention. Across all four scenarios, traditional banks retain approximately three-quarters of banking-system assets. Emerging technology-based business models, however, could capture between 3% and 27% of those assets, compared with approximately 3.5% under the trend-extrapolation baseline. But the most important finding is not the redistribution of assets. The report warns that technology-driven business models could contest approximately 40% of the banking industry's revenue pool. This can happen without a corresponding transfer of balance-sheet ownership. Payments, credit origination, customer relationships, distribution and advisory services can migrate towards technology companies and specialised platforms, while regulated banks continue to provide the funding, absorb losses and maintain the underlying balance-sheet exposures. In other words, banks can retain their assets while losing substantial parts of their economic business. This distinction is fundamental. The BIS identifies five essential economic functions of banking: Payment intermediation. Deposit-taking and short-term funding. Credit allocation and maturity transformation. Risk transformation and management. Investment and advisory services. These functions have traditionally been integrated within universal banks. Digitalisation allows them to be separated and performed by different organisations, sometimes connected through partnerships, platforms and external infrastructure. The SAP Capital Twin proposes a fundamentally different approach to this emerging architecture. It does not attempt to become another bank, another financial product or another payment platform. It provides an economic intelligence architecture connecting the operational reality of enterprises with financial intelligence, risk management and capital markets. Its ambition is to reconnect the five banking functions through a common understanding of the economic activities, contractual commitments and financial exposures that underpin them. The distinction is important: banking's next competitive advantage will not necessarily belong to the institution with the largest balance sheet or the most sophisticated digital interface. It may belong to the institution that understands economic reality most accurately and can translate that understanding into better financial decisions. 1. Payment Intermediation: From Executing Transactions to Understanding Their Economic Purpose The first banking function identified by the BIS is payment intermediation. Payments are among the easiest banking functions to separate from the traditional banking balance sheet. Technology companies, digital wallets, commerce platforms and specialised payment providers can establish direct relationships with customers while relying on regulated banks and existing financial infrastructure for settlement. This transformation is already reflected in the BIS scenarios. Under technology acceleration, payments migrate substantially towards non-bank interfaces while continuing to rely on bank rails. Under platform expansion, non-bank providers could perform retail payment intermediation end-to-end. The economic implications extend well beyond transaction processing. The provider controlling the customer interface can capture interchange, foreign-exchange and transaction fees. It can also acquire valuable information about customer behaviour, commercial activity and payment patterns. The bank may continue to hold the deposit and provide regulated settlement infrastructure while losing the relationship and the associated revenue. The question is therefore not simply how payments can be executed faster or more cheaply. It is who understands the economic activity that generates those payments and who captures the associated financial intelligence. This is where the Capital Twin introduces a different perspective. Within SAP environments, payments are not isolated financial events. They are the consequence of operational and contractual processes. A payment can be connected to a purchase order, a supplier contract, a production milestone, an inventory movement, a shipment, a delivery confirmation, an invoice or a collection. Each event provides information about the economic purpose, timing and financial consequences of a transaction. The Capital Twin connects these operational events with their financial implications. It allows payment decisions to be understood in the context of contractual obligations, expected cash flows, working capital requirements, foreign-exchange exposure and liquidity positions. This creates a distinction between payment execution and payment intelligence. SAP Pay can provide payment orchestration and execution. The Capital Twin provides the economic and financial context required to determine why a payment is necessary, when it should occur, how it affects liquidity and what associated financial risks should be considered. For example, a multinational manufacturer might have simultaneous payment obligations in several currencies, supplier commitments across multiple countries and expected collections associated with different delivery schedules. A conventional payment architecture executes the individual transactions. A Capital Twin architecture interprets those transactions within the company's wider economic position, allowing treasury and financial decision-making to consider liquidity, currency exposure, contractual commitments and financing requirements together. This is particularly relevant as the BIS identifies the growing importance of external platforms and interfaces in the distribution of financial services. Banks that remain limited to payment execution risk becoming infrastructure providers behind somebody else's customer relationship. Banks capable of connecting payment execution with operational and financial intelligence can retain a much more strategic role. The Capital Twin transforms payments from isolated financial transactions into financially contextualised economic events. 2. Deposit-Taking and Short-Term Funding: Understanding Liquidity Before It Becomes an Accounting Event The second function is deposit-taking and short-term funding. The BIS makes a particularly important distinction between owning a deposit and owning the customer relationship through which that deposit is accessed. Deposit-taking remains a regulated activity requiring the appropriate banking licence. However, a digital platform can control the customer interface, distribute a bank account and influence where customers hold their liquidity without necessarily owning the underlying deposit liability. This creates a structural asymmetry. The bank retains the funding obligation, but another organisation may control the customer relationship and the information that determines how quickly deposits move. Under the platform-expansion scenario, platforms increasingly intermediate access to deposits while the actual deposits remain within regulated banks. The report also identifies an important liquidity problem: digitalisation removes the physical and operational friction that historically made deposits relatively stable. Customers can transfer their money almost immediately. Information spreads quickly. Deposits become more confidence-sensitive, and the interval between a funding event and a potential capital event becomes considerably shorter. The March 2023 failures of US regional banks illustrate why this matters. The BIS argues that traditional assumptions about deposit stickiness and the speed of withdrawals need to be reconsidered. This is precisely where the Capital Twin and two of its central concepts, Contractual Gravity and Financial Airbnb, become relevant. Traditional liquidity management is heavily dependent on financial balances, expected cash flows, historical behaviour and established funding relationships. However, the economic reality of a company begins influencing liquidity requirements before those requirements appear in its accounting records. A supplier contract creates a future payment obligation. A confirmed customer order generates expected future receipts. Production commitments require raw materials, capacity and working capital. Goods in transit represent economic activity that has not yet completed its financial cycle. These events create future liquidity requirements or potential sources of liquidity. Contractual Gravity provides the conceptual framework for understanding how binding contractual commitments consume future liquidity before their accounting recognition. The Capital Twin brings these commitments into a forward-looking financial representation. Rather than considering liquidity solely through current balances and historical transactions, it connects future payment obligations and expected receipts with the operational processes that generate them. This creates opportunities for more accurate liquidity forecasting, financing planning and short-term funding allocation. Financial Airbnb introduces another dimension. Companies within interconnected SAP ecosystems frequently have simultaneous liquidity surpluses and financing requirements. One enterprise may have excess cash while another requires short-term financing to fulfil a confirmed production order, purchase raw materials or finance goods in transit. Financial Airbnb proposes connecting those complementary positions through financial matching, risk assessment and appropriate financial arrangements. The objective is not to eliminate banks as deposit-taking institutions. It is to create more efficient connections between real-economy liquidity providers and liquidity requirements, while respecting the regulatory and financial structures necessary to support those operations. The implications for banks are considerable. A bank with visibility into the operational and contractual economic reality of its corporate customers can improve its understanding of future liquidity requirements, anticipate financing demand and identify opportunities to provide treasury, funding and risk-management services. It can also improve its understanding of the liquidity exposures associated with third-party platforms and external financing arrangements. The Capital Twin moves liquidity intelligence from historical financial balances towards the future economic commitments that determine those balances. 3. Credit Allocation and Maturity Transformation: Financing Economic Reality Rather Than Merely Financial History The third function is credit allocation and maturity transformation. This is one of the most important sections of the BIS analysis because it identifies a structural change in the competitive advantage traditionally enjoyed by banks. Historically, relationship lending gave banks privileged access to borrower information. Banks knew their customers, understood their activities, observed their financial performance and accumulated information through long-term relationships. Digital platforms increasingly have access to different information sources. Transaction records, payroll information, commercial activity and platform interactions can be used to assess creditworthiness and influence the pricing and distribution of financing. The BIS identifies a crucial consequence: the informational advantage traditionally associated with relationship lending can migrate towards whoever controls the relevant data. This is particularly important for retail and small-business lending, where technology-based credit assessment can compete with established banking relationships. The report also highlights a distinction between originating a loan, funding it and retaining the resulting exposure. These activities do not necessarily belong to the same institution. A platform might acquire the customer, assess the borrower, select the credit product and determine its pricing. A regulated bank might provide the funds and retain the loan on its balance sheet. A credit fund might subsequently acquire some of the exposure. This creates a fragmented financing chain. Under the platform-expansion scenario, the BIS estimates that emerging models could account for 20-30% of banking-system assets. Given the assumed asset turnover and system growth, this corresponds to approximately 45% of gross new originations at the ten-year horizon. That 45% is an illustrative implication of the scenario assumptions, not an independent prediction. Nevertheless, the strategic message is unmistakable. The institution financing a loan may no longer be the institution controlling its origination, customer relationship or initial risk assessment. The SAP Capital Twin offers a different basis for credit intelligence. Its starting point is not simply the historical financial information available in a banking system or the transaction records generated by a digital platform. It is the operational evidence generated by the economic activity of the borrowing company. Through SAP environments, that evidence can include purchase orders, sales orders, supplier contracts, customer commitments, production plans, manufacturing capacity, inventory, work in progress, logistics, deliveries, invoices and payment obligations. These are not disconnected pieces of information. They represent different stages of the same economic activity. The Evidence Economy provides the foundation for connecting them and understanding the economic process behind a financing requirement. Consider a manufacturer receiving a confirmed order from an established customer. To fulfil that order, the manufacturer requires raw materials, production capacity, labour, logistics and working capital. A traditional financing assessment will examine the borrower's financial position, payment history, collateral, creditworthiness and contractual documentation. The Capital Twin introduces an additional dimension. It can connect the financing requirement with the operational evidence supporting the expected economic activity. It can interpret the relationship between the customer order, procurement commitments, production capacity, available inventory, delivery obligations and anticipated collections. This does not make the future cash flow certain. It does, however, provide a richer and more traceable basis for evaluating the economic assumptions behind the financing decision. The distinction becomes especially important when considering working capital, supply-chain finance, purchase-order finance, inventory financing, work-in-progress financing and goods-in-transit financing. Instead of treating each financing request as an isolated banking transaction, the Capital Twin can connect financing decisions with the operational processes that generate them. SAP Banking and Integrated Financial and Risk capabilities provide the financial modelling and risk language required to translate this operational evidence into credit exposures and financial assessments. The result is an opportunity to improve credit origination, risk differentiation, pricing and capital allocation. Financial Airbnb adds the possibility of connecting financing requirements with available corporate liquidity, creating opportunities for more direct financing relationships under appropriate contractual, regulatory and risk frameworks. However, one distinction from the BIS report must remain clear. Credit allocation can migrate towards platforms and specialised providers. Maturity transformation and the responsibility for funding longer-term exposures remain fundamentally connected to institutions with the necessary balance sheets and regulatory capacity. The Capital Twin does not eliminate that requirement. It improves the information and economic intelligence available to institutions performing that function. The Capital Twin changes the basis of credit intelligence: from assessing only the financial history of a borrower towards interpreting the operational evidence and contractual commitments that generate its future economic value. 4. Risk Transformation and Management: The Banking Function That Cannot Simply Be Outsourced The fourth function is risk transformation and management. This is perhaps the most significant finding in the entire BIS report. The authors conclude that risk transformation remains with traditional regulated banks across all four scenarios. Why? Because bearing unexpected financial losses requires more than technology or a customer interface. It requires a regulated institution with an appropriate licence, loss-absorbing balance-sheet capacity and access to the financial backstops that underpin the banking system. A platform can originate a loan, assess a borrower, distribute an investment product or manage a customer interface. But these activities do not automatically give that platform the capacity to absorb unexpected financial losses. This creates a paradox. Banks may lose the customer relationship, origination, distribution and advisory income while continuing to bear the financial risks generated by those activities. In some circumstances, the bank may even retain exposures that were originated and initially assessed by an external platform over which it has limited control. The BIS warns that this can produce new concentrations of operational dependency, partner risk and information asymmetry. For banks, this is potentially the most dangerous consequence of the unbundling of banking functions. They may retain the risk without retaining sufficient control over the information that explains its origin. This is precisely where Capital Twin becomes strategically relevant. Risk management cannot rely exclusively on the financial representation of an exposure at the moment it appears on a banking balance sheet. It needs to understand the underlying economic activity, the contractual relationships, the operational dependencies and the events that could change the exposure over time. The Capital Twin connects operational evidence with financial risk intelligence through SAP's enterprise and banking architecture. It provides the conceptual foundation for linking business events with credit risk, market risk, liquidity risk, operational exposure, collateral and capital requirements. For example, an exposure to a manufacturing company should not be interpreted exclusively through its historical financial statements and the outstanding amount of its loan. Its economic reality also depends on its order book, customers, suppliers, production capacity, inventory, contractual obligations, delivery performance and future collections. Changes in those variables can alter the expected performance of the business and the risks associated with its financing. SAP Analytical Banking and Integrated Financial and Risk capabilities provide the financial and risk-modelling environment through which operational information can be translated into banking concepts. This includes the assessment of probability of default, loss given default, exposure at default, risk-weighted assets and risk-adjusted returns. The Capital Twin connects these measurements with the wider economic activity that generates the exposures. The implications extend beyond individual credit assessments. Banks need to aggregate risk across legal entities, business units, countries, currencies, counterparties, products and economic relationships. The Basel Committee's BCBS 239 principles address precisely the underlying data-architecture problem: the ability of banks to aggregate risk exposures accurately, completely, consistently and in a timely manner. The Capital Twin's architecture is designed to address that structural challenge by connecting operational and financial evidence rather than relying exclusively on subsequent aggregation of fragmented records. The Evidence Economy provides traceability to the underlying business events. SAP provides the enterprise data and transaction architecture. SAP Banking and IFRA provide the financial interpretation. Capital Twin connects the elements into an integrated representation of economic and financial exposure. This is particularly important in a banking environment increasingly dependent on artificial intelligence. AI can accelerate risk analysis, identify patterns and process information at unprecedented scale. But an intelligent model cannot compensate for fragmented, inconsistent or insufficiently contextualised underlying data. The quality of financial intelligence depends on the quality, structure, provenance and interpretation of the evidence on which it operates. Capital Twin therefore does not attempt to replace risk management or the bank's responsibility for absorbing losses. It aims to give those responsible for managing risk a significantly richer understanding of the economic reality behind their exposures. The BIS identifies risk transformation as the function that remains with regulated banks. The Capital Twin provides the economic intelligence architecture those banks need to understand and manage the risks they continue to carry. 5. Investment and Advisory Services: From Selling Financial Products to Optimising Corporate Capital The fifth function is the provision of investment and advisory services. The BIS identifies this as another area where technology-based platforms can challenge traditional banks. Digital investment platforms, automated advisory services and embedded financial products can distribute investment solutions without requiring the provider to own a banking balance sheet. The customer relationship and associated advisory fees can therefore migrate towards organisations whose core business may not be financial services. Under the platform-expansion scenario, investment and advisory services become increasingly embedded within wider digital ecosystems. For traditional banks, this creates another potential loss of customer relationships and fee income. But there is a more fundamental strategic opportunity. Corporate financial advisory does not need to remain centred on the distribution of conventional banking products. A company does not necessarily need another loan, another foreign-exchange product or another bond in isolation. It needs the optimal combination of financing, liquidity, financial protection, collateral and capital allocation to fulfil its economic objectives. This is the distinction between financial product distribution and capital optimization. The SAP Capital Twin introduces the possibility of moving corporate banking towards an integrated capital-optimization model. A company operating within SAP may have simultaneous requirements involving supplier financing, customer financing, working capital, foreign-exchange hedging, bonds, guarantees, credit facilities, collateral and liquidity management. These requirements are connected through the company's real economic activity. An investment decision affects financing requirements. A procurement contract creates future liquidity obligations. A customer delivery generates an expected receivable. A change in the production plan may alter inventory requirements and working capital. An exchange-rate movement changes the value and risk of future cash flows. The Capital Twin brings these relationships into a common financial interpretation. This makes it possible to evaluate financial products according to the economic mission they are expected to fulfil. The relevant question becomes not simply which financial product should be sold, but which combination of financial instruments and contractual arrangements optimises the company's economic position. This can include the evaluation of different financing structures, the optimisation of FX exposures, the deployment of guarantees, the mobilisation of eligible collateral and the allocation of available liquidity. It also creates opportunities to connect investment and advisory services with the operational decisions of corporate customers. For banks, this could represent a new basis for differentiation. Rather than competing exclusively on interest rates, transaction fees and the distribution of standardised products, banks can become strategic partners in the optimisation of corporate capital. This also creates a potential commercial model based on financial intelligence, advisory services and the facilitation of more efficient capital allocation. The bank's competitive advantage would no longer depend exclusively on owning the customer interface or distributing the largest number of financial products. It would also depend on understanding the economic reality of its corporate customers and helping them optimise their financing and capital structures. The Capital Twin transforms corporate banking advisory from financial product distribution into integrated capital optimization. 6. The Four BIS Scenarios: Why Capital Twin Is Relevant Regardless of How Banking Evolves The BIS identifies four plausible scenarios for the future of banking. They are not predictions. They are structured configurations of technology, regulation, consumer preferences and macro-financial conditions designed to explore how different banking business models could evolve. The Capital Twin has strategic relevance in all four, although its role and commercial opportunities differ. Scenario 1: Slow Transformation In this scenario, technology diffuses gradually, regulation remains relatively stable and consumer preferences change incrementally. Traditional banks retain their existing functions, while new providers complement their services, particularly through digital payment interfaces. The banking model remains relatively close to its current structure. For banks, Capital Twin offers the opportunity to improve existing operations rather than waiting for disruptive competition to force transformation. It can connect the bank's corporate customers with their operational and financial reality, improve credit intelligence, enhance liquidity visibility and create more integrated advisory services. This scenario provides an opportunity to modernise the banking relationship before market structures change significantly. Scenario 2: Technology Acceleration In this scenario, digital adoption and artificial intelligence advance rapidly, while the regulatory perimeter remains broadly unchanged. Non-bank interfaces gain considerable importance in payments, and technology-based credit assessment begins displacing relationship-based lending in retail and small-business segments. Banks retain the majority of the balance sheet but face increasing competitive pressure on margins and customer relationships. The BIS identifies a potential divergence between large institutions capable of financing extensive digital transformation and mid-sized banks that increasingly become suppliers of funding and regulated infrastructure to external platforms. Capital Twin provides an opportunity to defend the bank's economic position through differentiated financial intelligence. Banks that can connect operational evidence with credit assessment, liquidity and risk management may be able to compete on information quality rather than simply on the cost of capital. For corporate customers, the architecture provides a more integrated relationship between operational decisions and financial services. For banks, it creates opportunities to improve origination, pricing, collateral assessment and risk-adjusted returns. Scenario 3: Platform Ecosystem Expansion This is the most disruptive scenario in the BIS study. Technology adoption, permissive regulation and consumer preferences combine to accelerate the expansion of platform-based financial services. Payments migrate towards external platforms. Credit origination and pricing migrate. Investment and advisory services become embedded in digital ecosystems. Platforms increasingly control customer relationships and financial distribution, while traditional banks retain a substantial proportion of the balance sheet and the associated risk transformation. Emerging models could capture 20-30% of banking-system assets, with approximately 45% of new origination in the illustrative ten-year scenario. The BIS warns that traditional banks could increasingly become suppliers of balance-sheet capacity and regulated infrastructure behind interfaces controlled by external providers. This scenario presents the strongest commercial argument for the Capital Twin. The principal challenge is the fragmentation of information and economic responsibility between the entity controlling the customer, the platform originating the financing, the bank funding it and the institution ultimately holding the exposure. Capital Twin can provide a common economic intelligence architecture connecting these participants through the evidence generated by the underlying business activities. It can improve the relationship between origination and balance-sheet risk by ensuring that financing decisions are linked to a more complete understanding of the economic activity that generates the exposure. It can also allow banks to develop differentiated financial services based on operational intelligence rather than competing solely as providers of regulated funding. In this environment, Capital Twin becomes more than a bank-modernisation initiative. It becomes a potential architecture for coordinating economic intelligence across a fragmented financial ecosystem. Scenario 4: Political Uncertainty The fourth scenario is particularly interesting because it demonstrates that technological disruption is not the only force shaping banking. Political and regulatory uncertainty increases, geopolitical fragmentation affects cross-border business models, funding becomes more expensive and consumers return towards familiar, insured banking institutions. Traditional banks regain market share within the banking system, and emerging technology-based models remain close to their current relative scale. However, the BIS identifies this as the scenario with the highest overall system-wide risk. The reason is that deteriorating macro-financial conditions affect every banking business model, weakening earnings, asset quality and capital generation. This is a crucial distinction. A banking system can experience higher systemic risk even when new competitors fail to gain market share. For Capital Twin, the implications are equally important. In an environment of geopolitical uncertainty, fragmented supply chains, currency volatility and changing regulatory conditions, banks and corporate customers need a reliable understanding of their contractual commitments, financial exposures and operational dependencies. The ability to connect procurement, production, inventory, logistics, deliveries, financing and foreign-exchange exposures provides an important basis for anticipating the consequences of external shocks. Capital Twin can support more informed funding decisions, liquidity planning, risk assessment and capital allocation under changing economic conditions. It does not eliminate geopolitical risk, market volatility or the need for capital buffers. It provides a stronger economic information architecture for understanding how those risks affect the real economy and the financial institutions connected to it. The four scenarios lead to the same conclusion. Whether banking evolves gradually, accelerates technologically, becomes dominated by platform-based distribution or retreats towards traditional regulated institutions, the ability to interpret economic reality remains strategically valuable. 7. Profitability, Liquidity and Solvency: The Three Dimensions That Connect Everything The title of the BIS paper is important. It does not examine technological disruption as an isolated competitive question. It evaluates how changes in banking functions affect profitability, liquidity and solvency. These three dimensions are interconnected. The Capital Twin is particularly relevant because it connects operational and financial intelligence across all three. Profitability: Protecting Margins and Generating Better Risk-Adjusted Returns The BIS identifies a structural pressure on traditional banking income. As payments, origination, distribution and advisory services migrate towards digital platforms, banks face pressure on net interest margins and fee income. Under platform expansion, the report suggests that net interest margins could compress by 20-40 basis points, particularly where platforms intermediate customer relationships while banks retain the underlying assets. The report also highlights the increasing volatility of fee-based and platform-generated revenues, together with the cost advantages achieved by digital-native providers. For traditional banks, the challenge is therefore not simply reducing operating costs. It is finding new ways to generate sustainable profitability. Capital Twin provides an opportunity to improve profitability through better information about the economic activity behind financial exposures. More accurate credit intelligence can support better differentiation of borrowers, more informed pricing and improved allocation of capital. Greater visibility into operational and contractual commitments can support more effective working-capital financing and financial advisory. Better integration between exposures, collateral and risk can also improve the understanding of risk-adjusted returns. The objective is not merely to increase the volume of lending. It is to improve the economic allocation of financial resources and the return generated for the capital employed. Liquidity: Moving from Historical Balances to Forward-Looking Economic Commitments Liquidity is particularly vulnerable to digital transformation. The BIS identifies the increasing speed of deposit movements as a structural challenge for traditional banks. Mobile banking and digital payment channels reduce the friction that historically made deposits relatively stable. Liquidity shocks can therefore develop much faster than traditional monitoring processes were designed to accommodate. Capital Twin introduces a forward-looking perspective. By connecting contractual obligations, expected collections, operational milestones and financing commitments, it can provide a more comprehensive understanding of future liquidity requirements. Contractual Gravity is especially relevant here. It recognises that financial commitments influence future liquidity before their accounting recognition. This allows the Capital Twin to incorporate contractual events into the economic representation of the company and its expected cash-flow requirements. Financial Airbnb complements this approach by connecting available liquidity with financing needs across corporate relationships. The combination can help banks and enterprises improve liquidity forecasting, financing allocation and treasury decisions. The objective is to make liquidity management more proactive and economically informed, rather than relying exclusively on historical balances and conventional cash-flow projections. Solvency: Connecting Financial Risk with the Economic Activity That Generates It The BIS argues that solvency increasingly depends on more than traditional credit risk and capital ratios. Operational resilience, third-party dependencies, earnings stability and the speed of liquidity transmission are becoming increasingly important. The report highlights a particularly serious development: the interval between a liquidity event and a solvency event can compress from weeks to days or even hours. This changes the requirements for risk management. Banks need to understand not only their current exposures, but also how those exposures depend on customers, platforms, operational processes, contractual relationships and external infrastructure. Capital Twin can provide a more integrated view of those dependencies. By connecting operational evidence with financial exposure and risk models, it creates a basis for better-informed decisions concerning credit, market risk, collateral, liquidity and capital allocation. It can support the identification of emerging risks before they are fully reflected in historical financial reporting. It can also contribute to stronger internal risk aggregation and a more coherent understanding of the exposures held across the institution. The fundamental objective is to connect the economic origins of risk with its financial representation and management. Profitability, liquidity and solvency should not be managed as disconnected financial outcomes. They are different consequences of the same underlying economic reality. 8. The Missing Architecture: From Enterprise Data to Financial Intelligence The BIS report identifies the reallocation of banking functions as a structural development. However, the underlying question is how banks and financial service providers will maintain a coherent understanding of the economic activities being financed when the organisations controlling those activities, their data and their financial exposures become increasingly separated. This is where the SAP architecture becomes strategically important. SAP is not simply another financial software provider. Its enterprise architecture is embedded in the operational processes through which large companies manage procurement, production, logistics, inventory, sales, deliveries, accounting and financial operations. These processes generate evidence about economic activity. S/4HANA provides an integrated financial and operational transaction architecture. SAP IBP supports planning and supply-chain coordination. Procurement and logistics applications capture commercial and operational events. Treasury and banking capabilities provide the financial context required to interpret the resulting exposures. The Capital Twin builds on this environment. Its purpose is to translate operational evidence into financial intelligence, connecting the real economy with the language of financial markets and banking risk. This introduces a distinction between three different representations of enterprise reality. The Digital Twin represents the physical state of assets and operations through telemetry, sensors and industrial data. The Financial Twin represents the historical accounting and financial state of the enterprise. The Capital Twin introduces a forward-looking representation of economic value, contractual commitments, expected cash flows, liquidity, financing needs and financial risk. This distinction is fundamental. An asset should not be evaluated exclusively according to what it physically is or what accounting category it occupies. Its economic significance also depends on the mission it must fulfil, the contractual relationships surrounding it, the cash flows it supports and the risks associated with those commitments. A warehouse inventory balance, for example, has a different financial meaning depending on whether the inventory is committed to a confirmed customer order, awaiting production, held as safety stock or exposed to market-price volatility. Likewise, a shipment in transit can represent a financed commercial transaction, an outstanding contractual obligation, a source of future receivables or a concentration of operational risk. Capital Twin seeks to interpret these circumstances within a common financial architecture. This requires more than access to raw data. It requires harmonised semantics, reliable source information, traceability, appropriate controls and a financial interpretation consistent with the requirements of banking and capital markets. That is why SAP Banking and Integrated Financial and Risk capabilities are essential to the proposition. They provide the connection between enterprise evidence and financial risk concepts, enabling operational information to be interpreted through the structures used in banking. The resulting architecture can support the aggregation of exposures, the evaluation of creditworthiness, the assessment of collateral and the optimisation of capital. It also creates a stronger basis for artificial intelligence. An autonomous financial system cannot rely exclusively on language models interpreting disconnected documents and unverified information. It needs structured, contextualised and governed information about the economic reality on which its decisions depend. Data without context is noise. Information without interpretation is inertia. The Capital Twin transforms enterprise evidence into financial intelligence, and financial intelligence into autonomous capital decisions. 9. Why the Capital Twin Is Not Another Banking Product The distinction between a banking product and an economic intelligence architecture is particularly important in the context of the BIS report. The five banking functions may be performed by different institutions. Payment execution can migrate to specialised platforms. Customer interfaces can be owned by technology companies. Credit origination can be separated from funding. Investment and advisory can become embedded in digital ecosystems. Risk transformation, however, remains closely linked to regulated balance sheets and loss-absorbing capacity. This means that financial institutions will increasingly need to coordinate activities performed by different organisations. Capital Twin is not designed to become a sixth banking function. It is designed to connect the five existing functions through a common understanding of economic reality. Its architecture is relevant to traditional banks, digital banks, financial platforms, corporate treasuries and other financial participants. A bank can use it to improve the information supporting credit and risk decisions. A platform can use it to connect financial distribution with the operational and contractual reality of corporate customers. An enterprise can use it to understand its financing needs, available liquidity, financial exposures and capital requirements. Financial institutions can use the resulting intelligence to evaluate financing opportunities and risk more effectively. The architecture therefore has a role across the financial ecosystem rather than being restricted to one particular institutional model. It is also important to distinguish the Capital Twin from a blockchain-based architecture. Its proposition does not depend on replacing enterprise transaction records with a decentralised ledger. The economic evidence already exists within operational and financial enterprise processes. The challenge is to integrate, contextualise and translate that evidence into financial intelligence. SAP provides the underlying enterprise architecture. Capital Twin provides the economic interpretation and financial intelligence layer. Artificial intelligence can then operate on top of that architecture to support increasingly autonomous decision-making, subject to appropriate governance and controls. This is a different approach to financial innovation: instead of creating another infrastructure to represent and transfer financial assets, it connects the economic reality behind those assets with the financial decisions that depend on it. 10. The Strategic Opportunity for Banks: From Balance-Sheet Providers to Capital Optimisation Partners The BIS report contains an important warning for traditional banking institutions. Retaining the balance sheet does not guarantee retaining the economic value of banking. An institution can continue to fund loans, absorb financial losses and satisfy regulatory capital requirements while losing the customer relationship, the origination activity, the distribution and a substantial share of associated income. This is particularly relevant under platform expansion. The bank risks becoming a regulated utility behind an interface controlled by another organisation. Its ability to compete will therefore depend not only on its balance-sheet strength but also on its ability to maintain economic relevance. The Capital Twin offers an opportunity to redefine that relationship. Instead of positioning itself exclusively as the provider of loans, payments, deposits and investment products, the bank can become a strategic partner in corporate capital optimisation. That means understanding the operational activity of its customers, interpreting their contractual commitments, anticipating financing needs, assessing their risk and identifying the financial instruments best suited to their economic objectives. This creates a broader relationship between banking and the real economy. For corporate customers, it means moving away from isolated financial transactions towards coordinated financial decisions. For banks, it creates opportunities for differentiated services and new revenue streams based on financial intelligence. For the wider economy, it creates the possibility of allocating capital more efficiently by connecting financing decisions with better evidence about the activities being financed. The significance should not be underestimated. The competitive advantage of future banking may depend less on who distributes the financial product and more on who understands the economic activity that creates the demand for it. Conclusion: The Future of Banking Belongs to Those Who Understand Economic Reality The BIS has identified a structural transformation of banking. The five core economic functions traditionally performed by integrated banking institutions are increasingly separable. Payments, deposit access, credit origination, distribution and advisory can migrate towards technology companies and specialised platforms. Traditional banks may continue to retain a substantial proportion of the balance sheet while facing pressure on customer relationships, income and profitability. At the same time, the responsibility for risk transformation remains closely connected to regulated financial institutions. The result is a more fragmented banking ecosystem in which economic relationships, customer information, operational responsibilities and financial exposures are distributed across different organisations. This creates a fundamental requirement: financial intelligence must connect the different participants with the economic reality underlying their activities. The SAP Capital Twin proposes precisely that architecture. It connects payment intermediation with operational events and contractual obligations. It connects deposit and funding decisions with forward-looking liquidity requirements and corporate cash-flow evidence. It connects credit allocation with production, inventory, procurement, logistics, deliveries and expected collections. It connects risk transformation with the underlying operational evidence supporting financial exposures. And it transforms investment and advisory services into an integrated model of corporate capital optimisation. The five functions are not five independent opportunities. They are interconnected dimensions of the same economic system. Profitability depends on how efficiently capital is allocated and how effectively financial services are monetised. Liquidity depends on understanding the timing and reliability of future economic commitments. Solvency depends on sustainable earnings, adequate capital and a reliable understanding of the risks accumulated across the financial ecosystem. The Capital Twin brings these dimensions together. It is not another banking product, another payment platform or another artificial intelligence application. It is a financial intelligence architecture built on the enterprise processes and data structures of SAP, designed to translate the operational reality of the economy into financial intelligence and autonomous capital decisions. The BIS has mapped the possible futures of banking. The strategic question for financial institutions is no longer simply how to automate their existing products or how to defend their traditional market positions. It is whether they can understand, orchestrate and optimise the economic reality behind the five functions they perform. The institutions that succeed in doing so will have an opportunity to compete on something much more valuable than transaction execution or distribution. They will compete on the quality of their economic intelligence and their ability to allocate capital accordingly. The future of banking will not be determined simply by who owns the balance sheet, but by who understands, orchestrates and optimises the economic reality behind it. SAP Capital Twin: From Banking Automation to Autonomous Capital Optimization. Primary reference: Christian Schmieder, Renzo Corrias and Oliver Wünsch, Bank for International Settlements, BIS Working Papers No. 1391, November 2026, "Scenarios for Future Banking: Implications for Profitability, Liquidity and Solvency." The study's four scenarios are structured illustrations based on expert judgement, not statistical forecasts. https://www.bis.org/publications/scenarios-future-banking-implications-profitability-liquidity-and-solvency Connect and Stay Informed: Join the Conversation: Connect with fellow professionals in the SAP Banking Group on LinkedIn. https://www.linkedin.com/groups/92860/ Stay Updated: Subscribe to the SAP Banking Newsletter for the latest insights. https://www.linkedin.com/newsletters/sap-banking-6893665983048081409/ Join my readers on Medium where I explore Capital Optimization in depth. Follow for actionable insights and fresh perspectives https://medium.com/@ferran.frances Explore More: Visit the SAP Banking Blog for in-depth articles and analyses. https://sapbank.blogspot.com/ Connect Personally: Feel free to send a LinkedIn invitation; I'm always open to connecting with like-minded individuals. ferran.frances@gmail.com I look forward to hearing your perspectives. Kindest Regards, Ferran Frances-Gil. #SAPRPT #SAPPay #SAPBN4L #ContractualGravity #CapitalTwin #SAP #CapitalOptimization #PredictiveFinance #SAPIFRA #AutonomousEnterprise #FerranFrances

The Capital Twin: Holistic Contract Optimization and the FX Paradox

Abstract Traditional enterprise management segregates commercial contracts into isolated operational and financial silos. Procurement, supply chain, and sales divisions evaluate agreements based on physical logistics costs, delivery schedules, and gross commercial margins, while corporate treasury independently manages liquidity, foreign exchange exposure, and regulatory capital charges at an aggregate ledger level. This structural fragmentation creates systemic capital inefficiencies and distorts commercial decision-making. By introducing the Capital Twin—a real-time digital financial twin synchronized with operational business networks—enterprises gain the ability to model the logistics costs, financial execution costs, and systemic capital consumption of a contract simultaneously and holistically. This paper examines the theoretical foundations of holistic contract modeling and demonstrates its transformative power through a classic corporate paradox: the evaluation of two operationally identical sales contracts, one denominated in local currency and the other in foreign currency. While conventional fragmented analysis systematically prioritizes the local currency contract to avoid perceived foreign exchange risk and capital penalties, a holistic Capital Twin evaluation reveals that the foreign currency contract can act as a natural, zero-cost hedge against pre-existing balance sheet exposures. Ultimately, the Capital Twin transforms commercial contracts from static revenue vehicles into dynamic instruments of enterprise risk mitigation and capital optimization. 1. The Structural Fragmentation of Traditional Contract Evaluation In legacy corporate architectures, the lifecycle of a commercial contract is fractured across disconnected functional domains. When an enterprise negotiates a major sales agreement or procurement commitment, the commercial and supply chain teams focus almost exclusively on physical execution parameters. They calculate manufacturing costs, raw material sourcing expenses, freight rates, warehousing overhead, customs duties, and delivery lead times. Once these operational variables are aggregated into a projected gross margin, the contract is deemed commercially viable and passes into execution. Treasury and corporate finance departments typically enter the equation only downstream, often weeks or months later, when purchase orders convert into invoices and accounts receivable or payable hit the general ledger. At that delayed stage, treasury aggregates these cash flows into broad currency buckets, calculates net open exposures, and executes external financial derivatives—such as forward contracts, swaps, or options—to hedge residual market risks. This temporal and structural separation imposes severe economic penalties on the enterprise: Blindness to Balance Sheet Interdependencies: Commercial teams negotiate contract terms—such as settlement currency, payment milestones, and incoterms—without real-time visibility into the enterprise's broader liquidity profile, existing foreign exchange exposures, or regulatory capital constraints. Delayed Risk Recognition: Because financial systems rely on lagging accounting entries rather than immediate operational commitments, treasury reacts to risks after they have already materialized on the balance sheet, forfeiting the opportunity to neutralize exposure structurally at the point of commercial origination. Suboptimal Capital Allocation: When financial costs and capital charges are calculated in isolation from logistics costs, organizations systematically misprice risk. A contract that appears low-risk on a standalone basis may inadvertently amplify systemic balance sheet volatility, whereas a contract that appears risky in isolation may actually reduce overall enterprise risk. Overcoming this fragmentation requires an architectural paradigm capable of fusing physical supply chain reality with real-time financial engineering before a contract is even signed. 2. The Capital Twin: Unifying Logistics, Finance, and Capital Architecture The Capital Twin resolves this structural divide by establishing a continuous, real-time digital mirror of the enterprise's financial and capital state, directly synchronized with operational execution systems. Operating alongside physical digital twins that track inventory, manufacturing capacity, and logistics networks, the Capital Twin ingests verified operational events from the Evidence Economy and translates them instantaneously into deterministic balance sheet projections via Contractual Gravity. Rather than treating logistics costs and financial costs as sequential, independent calculations, the Capital Twin models every commercial contract as a unified, multi-dimensional economic object. Within this holistic modeling environment, three distinct layers of contract economics converge into a single real-time optimization function: The Operational and Logistics Layer: Captures the exact physical cost structure of the agreement, including production schedules, transportation routes, inventory holding periods, fuel surcharges, and supply chain disruption probabilities. The Financial Execution Layer: Models the explicit and implicit financing mechanics embedded in the contract's lifecycle, including working capital velocity, payment term financing costs, counterparty credit spreads, and transactional foreign exchange conversion fees. The Systemic Capital and Risk Layer: Evaluates the marginal impact of the contract on the entire corporate balance sheet. It simulates how the contract's cash flows interact with existing assets, liabilities, multi-currency exposures, interest rate sensitivities, and risk-weighted asset (RWA) buffers. By computing these three layers simultaneously, the Capital Twin shifts enterprise decision-making from local optimization—maximizing the standalone margin of a single department—to global optimization, where every operational decision is calibrated to maximize total risk-adjusted return on capital across the entire corporation. 3. The Foreign Exchange Contract Paradox: A Case Study in Holistic Optimization To illustrate the profound strategic advantage of holistic contract modeling over traditional siloed evaluation, consider a foundational corporate finance dilemma: the Foreign Exchange Contract Paradox. 3.1. Defining the Operational Baseline Imagine a global industrial manufacturer whose functional and reporting currency is the Euro (EUR). Due to production capacity constraints at its primary European assembly facility, the company has capacity to fulfill only one additional major export order during the upcoming fiscal quarter. The commercial team has secured two competing, mutually exclusive contract proposals from reputable international buyers: Contract Alpha and Contract Beta. From a purely operational and physical logistics standpoint, Contract Alpha and Contract Beta are completely identical: Both contracts require the exact same bill of materials, manufacturing hours, and quality assurance protocols. Both agreements stipulate identical shipping volumes, packaging specifications, and freight routes to neighboring port terminals. Both contracts enforce identical delivery deadlines, milestone schedules, and 60-day post-delivery payment terms. At prevailing spot exchange rates, both contracts generate the exact same nominal gross revenue and yield an identical physical logistics profit margin. The sole point of divergence between the two agreements lies in their settlement currency: Contract Alpha is denominated and settled entirely in Euros (EUR), the manufacturer's local functional currency. Contract Beta is denominated and settled entirely in US Dollars (USD), a foreign currency relative to the manufacturer's reporting ledger. 3.2. The Flawed Verdict of Siloed, Non-Holistic Analysis In a conventional enterprise operating without a Capital Twin, the evaluation of these two contracts follows a predictable, fragmented path. The supply chain and logistics division reviews both proposals and declares complete indifference: the physical fulfillment costs, warehouse utilization, and freight logistics are identical. Consequently, the decision is escalated to the commercial finance and treasury risk controllers for a standalone financial assessment. Evaluating each contract in isolation, the traditional financial model applies standard risk-pricing heuristics: Evaluation of Contract Alpha (Local Currency - EUR): Because revenues are denominated in Euros and manufacturing and logistics costs are incurred primarily in Euros, Contract Alpha exhibits zero transactional foreign exchange volatility. Cash flows are predictable, no external hedging derivatives are required, and the contract consumes minimal economic capital buffers. Its net risk-adjusted margin remains intact. Evaluation of Contract Beta (Foreign Currency - USD): Viewed as an isolated transaction, Contract Beta introduces a naked long exposure to the US Dollar over the 90-day manufacturing and settlement cycle. If the USD depreciates against the EUR prior to settlement, the manufacturer's realized Euro revenue erodes directly. To protect the commercial margin, treasury must factor in the cost of executing a forward FX hedge, absorbing bid-ask spreads, bank intermediation fees, and credit line utilization charges. Alternatively, leaving the exposure unhedged requires allocating substantial internal risk capital (Value-at-Risk buffers) against currency volatility. Under this non-holistic, standalone framework, the verdict is unambiguous and seemingly indisputable: Contract Alpha is strictly superior. It delivers the exact same operational margin as Contract Beta while avoiding foreign exchange risk, hedging transaction costs, and incremental capital charges. A traditional enterprise will routinely prioritize Contract Alpha and reject Contract Beta—or penalize Contract Beta's pricing so heavily that the customer walks away. 3.3. Unveiling the Hidden Balance Sheet Reality Now introduce the crucial systemic variable that siloed contract evaluation fails to see: the enterprise's pre-existing balance sheet posture. Prior to evaluating Contract Alpha and Contract Beta, the manufacturer already carries a substantial, structural net short exposure in US Dollars. This pre-existing USD liability may stem from a variety of ongoing enterprise activities—such as long-term raw material supply agreements indexed to the US Dollar, scheduled USD-denominated debt service obligations, or capital expenditure commitments for imported machinery. Regardless of its specific origin, this existing exposure creates an active vulnerability: if the US Dollar appreciates against the Euro, the manufacturer suffers a direct financial loss on its existing obligations. To manage this pre-existing exposure, corporate treasury is currently forced to either bear ongoing balance sheet volatility or pay continuous financial friction costs to commercial banks to maintain external USD hedges. 3.4. The Capital Twin Resolution: The Contract as a Natural Hedge When this exact same scenario is processed through the Capital Twin, the analytical lens expands from the isolated transaction to the entire corporate balance sheet in real time. As soon as the parameters of Contract Alpha and Contract Beta are ingested into the Capital Twin simulation engine, the system maps their operational logistics costs alongside their systemic balance sheet interactions: Holistic Simulation of Contract Alpha (EUR): The Capital Twin confirms that Contract Alpha generates stable Euro cash inflows and incurs standard physical logistics costs. However, because Contract Alpha produces zero US Dollar inflows, it leaves the enterprise's pre-existing USD short exposure completely untouched. The treasury must continue carrying its systemic currency risk and paying external banking spreads to hedge its existing liabilities. Total enterprise risk remains elevated, and systemic capital consumption remains unchanged. Holistic Simulation of Contract Beta (USD): Rather than treating Contract Beta's US Dollar inflows as a standalone risk, the Capital Twin immediately recognizes their structural symmetry with the enterprise's existing USD liabilities. When modeled holistically, the incoming USD receivables from Contract Beta match the timing and magnitude of the outgoing USD obligations already sitting on the balance sheet. In the holistic simulation, Contract Beta ceases to be a source of foreign exchange risk; instead, it operates as a natural, internal financial hedge (a structural offset). By pairing the future USD inflows of Contract Beta against the pre-existing USD outflows, the Capital Twin demonstrates three transformative financial outcomes: Elimination of External Hedging Costs: The enterprise no longer needs to purchase costly external FX derivatives from commercial banks to cover either Contract Beta or the pre-existing USD liability. The two operational commitments neutralize each other organically, saving bid-ask spreads, structuring fees, and bank credit facility capacity. Release of Regulatory and Economic Capital: Because net enterprise-wide currency volatility drops toward zero, the Capital Twin recalculates the corporation's aggregate Value-at-Risk and regulatory capital buffers downward. Capital previously locked away to cushion against exchange rate swings is immediately freed for productive reinvestment. True Total Margin Superiority: When the avoided hedging expenses and the economic value of released capital buffers are credited directly to Contract Beta's holistic P&L, Contract Beta dramatically outperforms Contract Alpha in total risk-adjusted profitability—despite having identical physical logistics costs and nominal gross revenue. 4. Strategic Implications: From Revenue Vehicles to Balance Sheet Instruments The resolution of the Foreign Exchange Contract Paradox exposes a fundamental truth of modern financial engineering: the true economic value of a commercial contract cannot be measured in isolation from the balance sheet that absorbs it. When organizations evaluate contracts through fragmented operational and financial lenses, they systematically misallocate scarce production capacity and capital. By failing to connect supply chain execution with real-time treasury state, enterprises routinely reject naturally hedging commercial opportunities, overpay banking intermediaries for redundant financial derivatives, and trap excess liquidity in defensive risk buffers. The Capital Twin eliminates this blindness by embedding systemic financial intelligence directly into commercial and operational workflows. In a Capital Twin-enabled enterprise, sales teams, procurement officers, and supply chain planners do not operate in an informational vacuum. Real-time signals from the Capital Twin dynamically adjust commercial pricing hurdles and contract prioritization scores based on the live structural needs of the corporate balance sheet. If the enterprise carries an unhedged currency exposure, an interest rate mismatch, or a regional liquidity surplus, the Capital Twin automatically incentivizes commercial agreements whose operational cash flows naturally offset those imbalances. Conversely, if a proposed contract compounds an existing balance sheet concentration risk, the Capital Twin instantaneously prices that marginal capital penalty into the contract's approval threshold before commercial commitments are finalized. 5. Conclusion Holistic contract optimization represents the definitive convergence of supply chain management, financial engineering, and corporate strategy. Through the Capital Twin architecture, physical logistics costs, working capital mechanics, and systemic balance sheet risks are no longer analyzed as disconnected afterthoughts; they are unified into a single, continuous simulation model. As the Foreign Exchange Contract Paradox demonstrates, an agreement that appears risky or capital-intensive in isolation may in fact be the exact structural instrument required to neutralize pre-existing enterprise exposures. By revealing these hidden symmetries in real time, the Capital Twin elevates commercial contracts from mere sources of operational revenue into precision instruments of corporate risk management—unlocking superior capital efficiency, eliminating unnecessary banking friction, and establishing an enduring competitive advantage in global markets. Connect and Stay Informed: Join the Conversation: Connect with fellow professionals in the SAP Banking Group on LinkedIn. https://www.linkedin.com/groups/92860/ Stay Updated: Subscribe to the SAP Banking Newsletter for the latest insights. https://www.linkedin.com/newsletters/sap-banking-6893665983048081409/ Join my readers on Medium where I explore Capital Optimization in depth. Follow for actionable insights and fresh perspectives https://medium.com/@ferran.frances Explore More: Visit the SAP Banking Blog for in-depth articles and analyses. https://sapbank.blogspot.com/ Connect Personally: Feel free to send a LinkedIn invitation; I'm always open to connecting with like-minded individuals. ferran.frances@gmail.com I look forward to hearing your perspectives. Kindest Regards, Ferran Frances-Gil. #SAPRPT #SAPPay #CapitalOptimization #SupplyChainFinance #DigitalTransformation #CapitalTwin #IFRS9 #ContractualGravity #Joule #FerranFrances