The SAP Business Technology Platform (BTP) is not just a standalone product or a conventional module within SAP's suite of ERP systems; rather, it serves as a strategic platform from SAP, serving as the foundational underpinning for all company-wide innovations. In this article, we will delve deeper into some of the key offerings of SAP BTP for treasury and explore how it can contribute to driving innovation within treasury. 

The platform is designed to offer a versatile array of tools and services, aiming to enhance, extend, and seamlessly integrate with your existing SAP systems and other applications. Ultimately enabling a more efficient realization of your business objectives, delivering enhanced operational efficacy and flexibility. 

Analytics and AI 

One of the standout features of SAP BTP for treasury is its analytics and planning solution, SAP Analytics Cloud (SAC). This feature seamlessly connects with different data sources and other SAP applications. It supports Extended Planning & Analysis and Predictive Planning using machine learning models.  

At the core of SAC, various planning areas – like finance, supply chain, and workforce – are combined into a cloud-based interconnected plan. This plan is based on a single version of the truth, bringing planning content together. Enhanced by predictive AI and ML models, the plan achieves more accurate forecasting and supports near-real-time planning. Users can also compare different scenarios and perform what-if analysis to evaluate the impact of changes on the plan equipping organizations to prepare for uncertainties effectively. 

Application Development and Integration 

An organization's treasury architecture landscape often involves numerous systems, custom applications, and enhancements. However, this complexity can result in challenges related to maintenance, technical debt, and operational efficiency. 

Addressing these challenges, SAP BTP offers a solution known as the SAP Build apps tool. The tool enables users to adapt standard functionalities and create custom business applications through intuitive no-code/low-code tools. This allows that all custom development takes place outside your SAP ERP system, thereby preserving a ‘clean core’ of your SAP system. This will allow for a simpler, more streamlined maintenance process and a reduced risk of compatibility issues when upgrading to newer versions of SAP. 

In addition, SAP BTP facilitates seamless connectivity through a range of connectors and APIs integrated within the SAP Integration Suite. Enabling a harmonious integration of data and processes across diverse systems and applications, whether they are on-premise or cloud-based. 

Process Automation and Workflow Management 

Efficient process automation and workflow management play a pivotal role in enhancing treasury operations. SAP BTP offers an efficient solution named SAP Build Process Automation which enables users to design and oversee business processes using either low-code or no-code methods. It combines workflow management, robotic process automation, decision management, process visibility, and AI capabilities, all consolidated within a user-friendly interface.  

A significant advantage of SAP BTP's  workflow approach over conventional SAP workflows is the unification of workflows across diverse systems, including non-SAP systems and increased flexibility, enabling smoother interaction between processes and systems. 

The integration of SAP BTP for workflow with different SAP modules such as TRM, IHC, BAM is facilitated through the SAP Workflow Management APIs within your SAP S/4 HANA system. 

In the context of treasury functions, SAP Build Process Automation proves invaluable for automating and refining diverse processes such as cash management, risk management, liquidity planning, payment processing, and reporting. For instance, users can leverage the integrated AI functionalities for tasks like collecting bank statements/account balance information from different systems, consolidating information, saving and/or distributing the cash position information to the appropriate people and systems. Furthermore, the automation recorder can be employed to mechanize the extraction and input of data from diverse systems. Finally, the SAP Build Process Automation can also be utilized to create workflows for complex payment approval scenarios, including exceptions and escalations. 

Extensions to the Treasury Ecosystem 

SAP BTP extends the treasury ecosystem with multiple treasury-specific developed solutions, seamlessly enhancing your treasury SAP S/4 HANA system functionality. These extensions include: Multi-Bank Connectivity for simplified and secure banking interactions, SAP  Digital Payment Add-On for efficiently connecting to payment service providers. Trading Platform Integration for streamlined financial instrument trading, SAP Cloud for Credit Integration to assess business partner credit risk, SAP Taulia for Working Capital Management, Cash Application for automatic bank statement processing and cash application, and lastly, SAP Market Rates Management for the reliable retrieving of market data. 

Empowering organizations with extensive treasury needs by enabling them to selectively adopt these value-added capabilities and solutions offered by SAP. 

Alternatives to SAP BTP 

The primary driving factor to consider integrating SAP BTP as an addon to your SAP ERP is when there is an integrated company-wide approach towards adopting BTP. Furthermore, if the standard SAP functionalities fall short of meeting the specific demands of the treasury department, or if the need for seamless integration with other systems arises. 

It's important to prioritize the optimization of complex processes whenever feasible first, avoiding the pitfall of optimizing inherently flawed processes using advanced technologies such as SAP BTP. It is worth noting that the standard SAP functionality, which is already substantial, could very well suffice. Consequently, we recommend conducting an analysis of your processes first, utilizing the Zanders best practices process taxonomy, before deciding on possible technology solutions. 

Ultimately, while considering technology options, it's wise to explore offerings from best-of-breed  treasury solution providers as well – keeping in mind the potential need for integration with SAP. 

Getting Started 

The above highlights just a glimpse of SAP BTP's capabilities. SAP offers a free trial that allows users to explore its services. Instead of starting from scratch, you can leverage predefined business content such as intelligent RPA bots, workflow packages, predefined decision and business rules and over 170 open connectors with third-party products to get inspired. Some examples relevant for treasury include integration with Trading Brokers, S4HANA SAP Analytics Cloud, workflows designed for managing free-form payments and credit memos, as well as connectors linking to various accounting systems such as Netsuite Finance, Microsoft Dynamics, and Sage. 

Conclusion 

SAP BTP for Treasury is a powerful platform that can significantly enhance treasury. Its advanced analytics, app development and integration, and process automation capabilities enable organizations to gain valuable insights, automate tasks, and improve overall efficiency. If you are looking to revolutionize your treasury operations, SAP BTP is a compelling option to consider.  

Treasurers dealing with multiple jurisdictions, scattered banking landscape, and local requirements face many challenges in this regard. Japan is one of the markets where bank connectivity is indeed a challenge, especially when it comes to connecting with local banks.

Traditional options

The initial reaction from treasurers not familiar with local market conventions might be to seek connection through the SWIFT network. However, in Japan only a handful of banks offer SWIFT connectivity. Second natural choice is the Host-to-Host connection (H2H). This is the classic File Transfer Protocol (FTP), or preferably the secured version (sFTP) setup. Some will say old fashioned, rather than classic, since it is as old as the internet. Nonetheless, it is still popular, and frankly quite often the best fit for the purpose. However, if there are dozens of local banks to connect to, it can be difficult to be expected to connect to each of them with a direct H2H. While this could be technically feasible, it would be nothing short of a nightmare to maintain, with the initial setup being time-consuming in the first place.

Other solutions

There is an answer, or should we rather say ANSER, to this question. ANSER, an abbreviation of ‘Automatic answer Network System for Electrical Request’, is a data transfer system provided by NTT Data Corporation since 1981, which links banks with firms.[1] ANSER then is a way to connect a corporate client to the bank. The system has been around for a while, and together with Cash Management Service (CMS) centers it is a part of the so-called Firm Banking solution in Japan. Since its inception, ANSER offered a wider range of services, through which corporates could access their banking information. Among the offered channels are telephone, fax, firm banking terminal, and personal computer. With the ever-increasing need for speedy and accurate information exchange, the more traditional ways, such as telephone and fax, gave way to the more sophisticated and automated solution, namely eBAgent.

eBAgent making use of API

The said eBAgent is a proprietary middleware platform offered by NTT Data. The solution establishes an automated connection with banks through the above-mentioned ANSER network. In short, eBAgent offers a gateway to multiple local banking partners in Japan utilizing the ANSER network. The remaining part for the corporate is then to establish a connection between the TMS and eBAgent, and secure appropriate contracts with the eBAgent provider, NTT Data, as well as the banks.

As for the connection protocol, the choice is between the classic sFTP, or Application Programming Interface (API). The latter has the real-time advantage, with less lag between the pick-and-drop sFTP connection. API seems to be a choice for an increasing number of corporates these days in this area. What is also interesting, apart from the API connection, are the supported formats for transfers and bank statements. In addition to the local Japanese ZENGIN, the protocol also offers data transmission in a proprietary XML format. This XML format is actually quite simple, with a very limited amount of tags. In addition to this, unlike the ISO 20022 standard, it contains only one level of tags, without the nesting function. Depending on the exact ERP/TMS infrastructure, eBAgent can also provide conversion services from and to the IS 20022 standard. As for the connection to eBAgent, the whole setup seems easier said than done. However, some TMS providers, in response to the demand from the market, started offering off-the-shelf solutions for a plug-and-play connection to eBAgent. Kyriba and Reval already offer it, with SAP set to roll out its solution on the S/4HANA and Multi Bank Connectivity (MBC) platform in early 2024.

Various ways to connect TMS / ERP with banks in Japan

How to connect with local banks in Japan?

It all depends on the exact landscape of banks and systems. It may just as well turn out that a hybrid solution would be best suited. There is no one-size fits all, as each corporate is unique, thus careful consideration and design will be paramount for a stable and reliable connection with banks. One thing is certain, solutions that involve obtaining bank statement information and enact payments by telephone or fax are simply no longer sufficient. In this day and age, when much sensitive information is exchanged between corporates and banks, having a reliable, automated solution is indispensable.

If you would like to know more, do not hesitate to get in touch with Michal Zelazko via m.zelazko@zandersgroup.com or via + 81 (0) 8 3255 9966

[1] https://www.boj.or.jp/en/paym/outline/pay_boj/pss0305a.pdf

The EMIR Refit was originally introduced with the goal of simplifying regulations, and these new requirements took effect in 2019. Following the EMIR Refit, there has been a subsequent round of amendments and updated technical guidelines. In this article, we highlight the key changes. 

ESMA has published the final reporting guidelines for the updated EMIR refit to take effect on 29 April 2024 (Europe) and 30 September 2024 (UK). These changes, while strivinging to streamline and standardise the reporting across Trade repositories, will add some initial challenges in setting up the new report and reporting format. 

Although a significant number of corporates rely on the financial counterparty to report on their behalf, these changes can still cause a major headache for corporates that continue reporting by themselves or need to report internal trades. 

Key changes  

The first major change concerns the number of fields that can be reported on. Currently there are 129 reportable fields, under the updated legislation there is a withdrawal of 15 and 89 new fields. This brings the new report to a hefty 203 reportable fields. 

There will be an introduction of more counterparty-specific fields. These fields will require a deeper understanding of and communication with all counterparties. New counterparty data that will be required includes a Clearing Threshold and Corporate Sector. 

The way that these fields will be reported is under huge review. The updated legislation will remove the CSV file, a business staple due to its ease of creation and flexibility, and replace the file with an XML submission using ISO 20022 standards. This move to XML will give corporates the headache of building the necessary XML file. One benefit of the XML format is that it will make moving between Trade Repositories easier as there will be a uniform file specification.  

Introducing UPI 

Another major change concerns the introduction of a Unique Product Identifier (UPI). The UPI is aimed at reducing the misreporting of products, ISINs, CFI codes, and other classifications. The UPI will be controlled and issued by the Derivatives Service Bureau (DSB). With a central database of identifiers, this should reduce misreporting. It is also hoped that the use of a centrally managed UPI will lead to a reduction in the number of reportable fields in the future . A downside to this change is that companies will need to sign up with the DSB and a fee will be charged for each UPI. There is a general consensus that with the introduction of the UPI, the UTI is likely to be phased out and removed in the future. 

One easily missed detail on the new requirements is the necessity to update all outstanding trades to the new reporting format and level of detail, within 6 months of the go-live. This can be problematic for firms that don’t have the necessary data points for the historic trades and will require a review to bring these trades up to the required reporting standard. 

In summary, there are large changes in the number of fields needing to be reported, much more granularity required from dealing counterparties, and a change of file type to XML. 

Reporting validations and final report can be found on the ESMA website. 

With our experience in EMIR and EMIR Refit legislation we can help with the transition to the new reporting requirements. 

Please contact Keith Tolfrey or Wilco Noteboom for further insights. 

First and foremost, the long period of low and even negative swap rates was followed by strongly rising rates and a volatile market, which impacted the behavior of both customers and banks themselves. At the same time, regulatory developments, initiated by EBA’s new IRRBB guidelines, have shifted the banks’ focus to managing their earnings and earnings risk, rather than economic value risks.  

Non-maturing deposits (NMDs) are of particular interest in this respect, given the uncertainty regarding the future pricing strategy and volume developments involved in these products. Moreover, as NMDs are generally modeled with a rather short maturity, the portfolio plays a significant role in the stability of the NII, making this portfolio even more relevant to evaluate in light of the newly introduced Supervisory Outlier Test (SOT) limits on earnings risk (more specific NII), or the local equivalent. 

How does this affect IRRBB management at banks?

The exact impact of these developments is also heavily dependent on the bank’s local market, and corresponding laws and regulation, as well as the balance sheet composition of the bank. In Nordics countries, banks are affected more heavily, given that loans and mortgages generally have shorter maturities, as compared to other Western European countries like Germany and the Netherlands. This yields a smaller maturity mismatch with on-demand deposits at the liability side, such that a natural hedge exists to some extent within the balance sheet. Earlier on, this effect, combined with the rather stable markets, made active ALM, including IRRBB management, less urgent. The incentive to accurately model NMDs was therefore limited, so most banks simply replicate this funding overnight, while banks in other European countries tend to use a longer maturity, as illustrated by figure 1.

{Figure 1: Difference in average repricing maturity of NMDs between Nordic banks and other European banks, based on Pillar 3 IRRBBA and IRRBB1 disclosures from 2022 annual reports}

While the natural hedge already (partially) mitigates the risks from a value perspective to a large extent, investing the full NMDs portfolio overnight leads to relatively high NII volatility, thereby potentially violating regulatory limitations. The return on overnight investments will directly reflect any changes in the market rates, while deposit rates in reality are usually somewhat slower to include such developments. Although the resulting asymmetry between the investment return and deposit rate to be paid to customers yields a positive result under rising interest rates, it can reduce profits when interest rates start to fall.  

Historically, banks in the Nordics experienced less flexibility in the modeling of NMDs, due to regulatory guidelines being somewhat stricter than EBA guidelines. For instance, Sweden’s Finansinspektionen (FI) required banks to replicate these positions overnight. However, relatively recently, the FI updated its regulations (FI dnr 19-4434), allowing banks to somewhat extend the duration of the investment profile, for a limited portion of the portfolio, and up to a maturity of one year. This results in flexibility to update the investment profile to better reflect the expected repricing speed of deposit rates, which could lead to improved NII stability. Additionally, besides applying these revised NMD models for managing banking book risks, they can, when approved, also be used for effective and consistent capital charge calculations under Pillar 2. 

How can these developments be properly managed? 

Even though the recent market developments create additional challenges in IRRBB management for banks, they also provide opportunities. The margin on deposit products for banks is currently improving, since only part of the interest rate rises is passed through to customers. The increased interest rates also mean that more advanced NMD models, with longer maturity profiles, can have a positive impact on the P&L, while simultaneously improving the interest rate risk management. 

In such a rare win-win situation, it is more advantageous than ever to prioritize NMD modeling. In reassessing the interest rate risk management approach towards NMDs, banks should explicitly balance the tradeoff between value and earnings stability when making conceptual choices. These conceptual choices should align with the overall IRBBB strategy, as well as the intended use of the model, to ensure the risk in the portfolio is properly managed. 

In weighing these conceptual alternatives, it is essential to take portfolio-specific characteristics into account. This requires an analysis of historical behavior, and an interpretation of how representative this information is. If behavior is expected to change, a common approach is to supplement historical data with expert expectations of forward-looking scenarios to develop a model that reflects both. Periodically reassessing the conceptual choices ensures a proper model lifecycle of NMD portfolios. This is crucial for accurate measurement of interest rate risk as well as for staying competitive in the current market environment. 

Would you like to hear more? Contact Bas van Oers for questions on developing a non-maturing deposit model.

On Thursday 15 June 2023, Zanders hosted a roundtable on ‘Climate Scenario Design & Stress Testing’. In our head office in Utrecht, we welcomed risk managers from several Dutch banks. This article discusses our view on the topic and highlights key insights from the roundtable. 

In recent years, many banks took their first steps in the integration of climate and environmental (C&E) risks into their risk management frameworks. The initial work on climate-related risk modeling often took the form of scenario analysis and stress testing. For example, as part of the Internal Capital Adequacy Assessment Process (ICAAP) or by participating in the 2022 Climate Stress Test by the European Central Bank (ECB). To comply with the ECB’s expectations on C&E risks, banks are actively exploring methodologies and data sources for adequate climate scenario design and stress testing. The ECB requires that banks will meet their expectations on this topic by 31 December 2024. 

Our view

We believe that banks should start early with climate stress testing, but in a manageable and pragmatic way. Banks can then improve their methodologies and extend their scope over time. This allows for a gradual development of knowledge, data and methodologies within all relevant Risk teams. Zanders has identified the following steps in the process of climate scenario design and stress testing: 

• Step 1: Scenario selection 
  A bank has to select appropriate (climate) scenarios based on the bank’s climate risk materiality assessment. Important to consider in this phase is the purpose for which the scenarios will be used, whether the scenarios are in line with scientific pathways, and whether they account for different policy outcomes (like an early or late transition to a sustainable economy). 

• Step 2: Scope and variable definition 
  An appropriate scope must then be selected and appropriate variables defined. For example, banks need to determine which portfolios to take in scope, which time horizons to include, select the granularity of the output, the right level of stress, and which climate- and macro-economic variables to consider. 

• Step 3: Methodology 
  Then, the bank needs to develop methodologies to calculate the impact of the scenarios. There are no one-size-fits-all approaches and often a combination of different qualitative and quantitative methodologies is needed. We recommend that the climate stress test approach be initially simple and to focus on material exposures. 

• Step 4: Results 
  It is important to use the results of the scenario analysis in the relevant risk and business processes. The results can be used for the bank’s risk appetite and strategy. The results can also help to create awareness and understanding among internal stakeholders, and support external disclosures and compliance. 

• Step 5: Stress testing framework 
  Finally, banks should establish minimum standards for climate scenario design and stress testing. This framework should include, amongst others, policies and processes for data collection from different sources, how adequate knowledge and resources are ensured, and how the scenarios are kept up-to-date with the latest market developments. 

Key insights 

Prior to the roundtable, participants filled in a survey related to the progress, scope and challenges on climate risk stress testing. The key insights presented below are based on the results of this survey, together with the outcomes of the discussion thereafter. 

The financial sector has advanced with several aspects around integrating climate risks in risk management over the past year. This was recognized by all participants, as they had all performed some form of climate risk stress testing. The scope of the stress testing, however, was relatively limited in some cases. For example, all participants considered credit risk in their climate risk scenario with many also including market risk. Only a limited number of participants took other risk types into account. 

Furthermore, all participants assessed the short-term impact (up to 3 years) of the climate scenarios, whereas only around 40% and 10% assessed the impact on the medium term (3 to 10 years) and long term (>10 years), respectively. This is probably related to the fact that all participants used climate scenarios in their ICAAP, which typically covers a three-year horizon. The second most mentioned use for the climate scenarios, after the ICAAP, was the risk identification & materiality analysis. A smaller percentage of participants also used the climate scenarios for business strategy setting, ILAAP and portfolio management. 

The two topics that were unanimously mentioned as the main challenges in climate risk stress testing are data selection and gathering, and the quantification of climate risks into financial impacts, as shown in the graph below: 

• Insight 1: Assessing impact of climate risk beyond the short-term very much increases the complexity and uncertainty of the exercise 
  The participants indicated that climate stress testing beyond the short-term horizon (beyond 3 to 5 years) is very difficult. Beyond that horizon, the complexity of the (climate) scenarios increases materially due to uncertainties of clients’ transition plans, the bank’s own transition plan and climate strategy (e.g., related to pricing and client acceptance policies), and climate policies and actions from governments and regulators. Taking the transition plans of clients into account on a granular level is especially difficult when there is a large number of counterparties. There are no clear solutions to this. Some ideas that take longer-term effects into account were floated, such as adjusting the current valuation of various assets by translating future climate impact on assets into a net present value of impact or by taking climate impacts into account in the long-term macro-economic scenarios of IFRS9 models. 

• Insight 2: Whether to use a top-down or bottom-up approach depends on the circumstances 
  It was discussed whether a bottom-up stress test for climate scenarios is preferable to a top-down stress test. The consensus was that this depends on the circumstances, for example: 
  • Physical risks are asset- and location-specific; one street may flood but not the next. So, in that case a bottom-up assessment may be necessary for a more granular approach. On the other hand, for transition risks, less granularity might be sufficient as transition policies are defined on national or even supranational level, and trends and developments often materialize on sector-level. In those cases, a top-down type of analysis could be sufficient. 
  • If the climate stress test is used to get a general overview of where risks are concentrated, a top-down analysis may be appropriate. However, if it is used to steer clients, a more granular, bottom-up approach may be needed. 
  • A bottom-up approach could also be more suitable for longer-term scenarios as it allows to include counterparty-specific transition plans. For more short-term scenarios, a sector average may be sufficient, considering that there will be less transition during this period.

• Insight 3: Translating the results of climate risk stress testing into concrete actions is challenging 
  The results of the stress test can be used to further integrate climate risk into risk management processes such as materiality assessment, risk appetite, pricing, and client acceptance. Most participants, however, were still hesitant to link any binding actions to the results, such as setting risk limits (e.g., limiting exposures to a certain sector), adjusting client acceptance, or amending pricing policies. However, the ECB does require banks to consider climate impacts in these processes. The most mentioned uses of the climate risk stress testing results were risk identification & materiality assessments and risk monitoring.  

Conclusion 

Most banks have taken first steps in relation to climate scenario design and stress testing. However, many challenges still remain, for example around data selection and quantification methodologies. Efforts by banks, regulators and the market in general are required to overcome these challenges. 

Zanders has already supported several banks with climate scenario design and stress testing. This includes the creation of a climate scenario design framework, the definition of climate scenarios, and by quantifying climate risk impacts for the ICAAP. Next to that, we have performed research on modeling approaches that can be used to quantify the impact of transition and physical risks. If you are interested to know how we can help your organization with this, please reach out to Marije Wiersma.

Seventy banks have been considered, which is an increase of twenty banks compared to the previous exercise.  The portfolios of the participating banks contain around three quarters of all EU banking assets (Euro and non-Euro).  

Interested in how the four Dutch banks participating in this EBA stress test exercise performed? In this short note we  compare them with the EU average as represented in the results published [1].   

General comments

The general conclusion from the EU wide stress test results is that EU banks seem sufficiently capitalized. We quote the main 5 points as highlighted in the EBA press release [1]: 

• The results of the 2023 EU-wide stress test show that European banks remain resilient under an adverse scenario which combines a severe EU and global recession, increasing interest rates and higher credit spreads. 
   
• This resilience of EU banks partly reflects a solid capital position at the start of the exercise, with an average fully-loaded CET1 ratio of 15% which allows banks to withstand the capital depletion under the adverse scenario. 
   

• The capital depletion under the adverse stress test scenario is 459 bps, resulting in a fully loaded CET1 ratio at the end of the scenario of 10.4%. Higher earnings and better asset quality at the beginning of the 2023 both help moderate capital depletion under the adverse scenario. 
   
• Despite combined losses of EUR 496bn, EU banks remain sufficiently apitalized to continue to support the economy also in times of severe stress. 
   
• The high current level of macroeconomic uncertainty shows however the importance of remaining vigilant and that both supervisors and banks should be prepared for a possible worsening of economic conditions. 

For further details we refer to the full EBA report [1]. 

Dutch banks

Making the case for transparency across the banking sector, the EBA has released a detailed breakdown of relevant figures for each individual bank. We use some of this data to gain further insight into the performance of the main Dutch banks versus the EU average.

CET1 ratios

Using the data presented by EBA [2], we display the evolution of the fully loaded CET1 ratio for the four banks versus the average over all EU banks in the figure below. The four Dutch banks are: ING, Rabobank, ABN AMRO and de Volksbank, ordered by size.

From the figure, we observe the following: 

• Compared to the average EU-wide CET1 ratio (indicated by the horizontal lines in the graph above), it can be observed that three out of four of the banks are very close to the EU average. 
• For the average EU wide CET1 ratio we observe a significant drop from year 1 to year 2, while for the Dutch banks the impact of the stress is more spread out over the full scenario horizon.  
• The impact after year 4 of the stress horizon is more severe than the EU average for three out of four of the Dutch banks.  

Evolution of retail mortgages during adverse scenario

The most important product the four Dutch banks have in common are the retail mortgages. We look at the evolution of the retail mortgage portfolios of the Dutch banks compared to the EU average. Using EBA data provided [2], we summarize this in the following chart:

Based on the analysis above , we observe: 

• There is a noticeable variation between the banks regarding the migrations between the IFRS stages. 
• Compared to the EU average there are much less mortgages with a significant increase in credit risk (migrations to IFRS stage 2) for the Dutch banks. For some banks the percentage of loans in stage 2 is stable or even decreases. 

Conclusion

This short note gives some indication of specifics of the 2023 EBA stress applied to the four main Dutch banks.

Should you wish to go deeper into this subject, Zanders has both the expertise and track record to assist financial organisations with all aspects of stress testing. Please get in touch.

References

1. EU-wide stress testing | European Banking Authority (europa.eu) 

2. https://www.eba.europa.eu/assets/st23/full_database/TRA_CRE_IRB.csv  
    

The CSP helps reinforce the controls protecting participants from cyberattack and ensures their effectivity and that they adhere to the current Swift security requirements.

*Swift does not certify, warrant, endorse or recommend any service provider listed in its directory and Swift customers are not required to use providers listed in the directory. 

Swift Customer Security Programme 

A new attestation must be submitted at least once a year between July and December, and also any time a change in architecture or compliance status occurs. Customer attestation and independent assessment of the CSCF v2023 version is now open and valid until 31 December 2023. July 2023 also marks the release of Swifts CSCF v2024 for early consultation, which is valid until 31 December 2024.   

Swift introduced the Customer Security Programme to promote cybersecurity amongst its customers with the core component of the CSP being the Customer Security Controls Framework (CSCF).​ Independent assessment has been introduced as a prerequisite for attestation to enhance the integrity, consistency, and accuracy of attestations. Each year, Swift releases an updated version of the CSCF that needs to be attested to with support of an independent assessment.  

The Attestation is a declaration of compliance with the Swift Customer Security Controls Policy and is submitted via the Swift KYC-SA tool. Dependent on the Swift Architecture used, the number of controls to be implemented vary; of which certain are mandatory, and others advisory.​ 

Further details on the Swift CSCF can be found on their website:

• https://www.swift.com/myswift/customer-security-programme-csp 
• https://www.swift.com/myswift/customer-security-programme-csp/find-external-support/directory-csp-assessment-providers

Our services 

Do you have arrangements in place to complete the independent assessment required to support the attestation?  

Zanders has experience with and can support the completion of an independent external assessment of your compliance to the Swift Customer Security Control Framework that can then be used to fully complete and sign-off the Swift attestation for this year.​  

With an extensive track record of designing and deploying bank integrations, our intricate knowledge of treasury systems across both IT architecture as well as business processes positions us well to be a trusted independent assessor. We draw on past projects and assessments to ask the right questions during the assessment phase, aligning our customers with the framework provided by Swift.  

The Swift attestation can also form part of a wider initiative to further optimise your banking landscape, whether that be increasing the use of Swift within your organisation, bank rationalization or improving your existing processes. The availability of your published attestation and its possible consultation with counterparties (upon request) helps equally in performing day-to-day risk management. 

Approach 

Planning 

We start with rigorous planning of the assessment project, developing a scope of work and planning resources accordingly. Our team of experts will work with clients to formulate an Impact Assessment based on the most recent version of the Swift Customer Security Controls Framework. 

Architecture Classification 

A key part of our support will be working with the client to formulate a comprehensive overview of the system architecture and identify the applicable controls dictated by the CSCF.  

Perform Assessment 

Using our wide-ranging experience, we will test the individual controls against specific scenarios designed to root out any weaknesses and document evidence of their compliance or where they can be improved.  

Independent Assessment Report 

Based on the evidence collected, we will prepare an Independent Assessment report which includes status of the compliance against individual controls, baselining them against the CSCF and recommendations for improvement areas within the system architecture.  

Post Assessment Activities 

Once completed, the Independent Assessment report will support you with the submission of the Attestation in line with the requirements of the CSCF version in force, which is required annually by Swift. In tandem, Zanders can deliver a plan for implementation of the recommendations within the report to ensure compliance with current and future years’ attestations. Swift expects controls compliance annually, together with the submission of the attestation by 31 December at the latest, in order to avoid being reported to your supervisor. Non-compliant status is visible to your counterparties. 

Do you need support with your Swift CSP Independent Assessment?  

We are thrilled to offer a Swift CSP Independent Assessment service and look forward to supporting our clients with their attestations, continuing their commitment to protecting the integrity of the Swift network, and in doing so supporting their businesses too. If you are interested in learning more about our services, please contact us directly below.  

Machine learning (ML) models have proven to be highly effective in the field of credit risk,
outperforming traditional regression models in their predictive power. Thanks to the exponential growth in the data availability, storage capacity and computational power, these models can be effectively trained on vast amounts of complex, unstructured data.

Despite these advantages, however, ML models have yet to be integrated into internal rating-based (IRB) modeling methodologies used by banks. This is mainly due to the fact that existing methods for calculating regulatory capital have remained largely unchanged for over 15 years, and the complexity of ML models can make it difficult to comply with the Capital Requirements Regulation (CRR). Nonetheless, the European Banking Authority (EBA) recognizes the potential of ML in the future of IRB modeling and is considering providing a set of principle-based recommendations to ensure its appropriate use.

In sight of these recommendations, the EBA published a discussion paper (EBA/DP/2021/04) to seek stakeholders’ feedback on the practical use of ML in the context of IRB modeling, aiming to provide clarity on supervisory expectations. This paper outlines the challenges and opportunities in using ML to develop CRR-compliant IRB models, and presents the point of view for various banking stakeholders on the topic.

Current use and potential benefits of ML in IRB models

According to research conducted by the Institute of International Finance (IIF) in 2019, the most
common uses of ML within credit risk are credit approval, credit monitoring and collections, and
restructuring and recovery. However, the use of ML within other regulatory areas, such as capital
requirements, stress testing and provisioning is highly limited. For IRB models, ML is used to
complement standard models used for capital requirement calculation. Examples of current uses of ML to complement standard models include (i) model validation, where the ML model serves as a challenger model, (ii) data improvements, where ML is used for more efficient data preparation and exploration, and (iii) variable selection, where ML is used to detect explanatory variables.

ML has the potential to provide a range of benefits for risk differentiation, including improvements in the model discriminatory power 1 , identification of relevant risk drivers 2 , and optimization of the portfolio segmentation. Based on their superior predictive ability and capacity to detect bias , ML models can also help to improve risk quantification 3 . Furthermore, ML can be used to enhance the data collection and preparation process, leading to improved data quality. Finally, ML models can enable the use of unstructured data, expanding the possible data sets allowing for the use of new parameters and estimation of these parameters.

Challenges to CRR compliance

The following table summarizes the challenges involved in using ML to develop IRB models that are compliant to prudential requirements.

Expectations for a possible and prudent use of ML in IRB modeling

In January 2020, the EBA published a report on the recent trends of big data and advanced analytics (BD&AA) in the banking sector. In order to support ongoing technological neutrality – the freedom to choose the most appropriate technology adequate to their needs and requirements - the BD&AA report recommends the use of ML and suggests safeguards to ensure compliance. Meanwhile, the EBA has provided the following principles to clarify how to adhere to the regulatory requirements set out in the CRR for IRB models.

• All relevant stakeholders should have an appropriate level of knowledge of the model’s functioning. This includes the model development unit, credit risk control unit and validation unit, but also the management body and senior management, to a lesser extent.
  • Zanders believes that appropriate trainings on the use of ML to the relevant stakeholders ensures the appropriate level of knowledge.
• Institutions should avoid unnecessary complexity in the modeling approach if it is not justified by a significant improvement in the predictive capabilities. 
  • Zanders advocates to focus on the use of explanatory drivers with significant predictive information to avoid including an excessive number of drivers. In addition, Zanders advises on which data type (unstructured or more conventional) and what modeling choice (simplistic or sophisticated) is appropriate for the institution to avoid unnecessary complexity.
• Institutions should ensure that the model is correctly interpreted and understood by relevant stakeholders.
  • Zanders assesses the relationship of each single risk driver with the output variable, ceteris paribus, the weight of each risk driver to detect the level of influence on the model prediction, the economic relationship to ensure plausible and intuitive estimates, and the potential biases in the model, such that the model is correctly interpreted and understood.
• The application of human judgement in the development of the model and in performing overrides should be understood in terms of economic meaning, model logic, and model behavior. 
  • Zanders provides best market practice expertise in applying human judgement in the development and application of the model.
• The parameters of the model should generally be stable. Therefore, institutions should perform sensitivity analysis and identify/monitor reasons for regular updates.
  • Zanders analyses whether a break in the economic conditions or in the institution’s processes or in the underlying data might justify a model update. Furthermore, Zanders evaluates the changes required to obtain stable parameters over a longer time horizon.
• Institutions should have a reliable validation, which covers overfitting issues, challenging the model design, reviewing representativeness and data quality issues, and analyzing the stability of estimates. 
  • Zanders provides validation activities following regulatory compliance.

Survey responses

The following stakeholders provided responses to the questions posed in the EBA paper (EBA/DP/2021/04):

1. Asociación Española de Banca (AEB) – Spanish Banking Association
2. Assilea – Italian Leasing Association
3. Association for Financial Markets in Europe (AFME)
4. European Association of Co-operative Banks (EACB)
5. European Savings and Retail Banking Group (ESBG)
6. Fédération Bancaire Française - French Banking Federation (FBF)
7. Die deutsche Kreditwirtschaft – The German Banking Industry Committee (GBIC)
8. Institute of International Finance (IIF)
9. Mazars – audit, tax and advisory firm
10. Prometeia SpA – advisory and tech solutions firm (SpA)
11. Banca Intesa Sanpaolo – Italian international banking group (IIBG)

A summary of the responses to key questions is provided below.

The vast majority of respondents does not currently apply ML for IRB purposes. The respondents argue that they would like to use ML for regulatory capital modeling, but that this is not deemed feasible without explicit regulatory guidelines and certainty in the supervisory process. AEB refers to the report published by the Bank of Spain in February 2021, where it was concluded that ML models perform better than traditional models in estimating the default rate, and that the potential economic benefits would be significant for financial institutions. AECB and GBIC indicate that the need for ML in regulatory capital modeling is currently not necessary as the predictive power of traditional models prove to be satisfactory. Three respondents presently use ML to some extent within IRB, such as for risk driver selection and risk differentiation. Only IIBG has actually developed a complete ML model for the estimation of PD of an SME retail portfolio, which has been validated by the supervisor in 2021.

Five respondents answer that they would outsource the ML modeling for IRB to different degrees. AEB states that most of the work will be done internally and consulting services will be required at peak planning times. According to Mazars, the outsourcing is mainly performed on the development phase as banks would take over the ownership of the model and implement it in its IT infrastructure internally. The other respondents that plan to outsource foresee that external support is required for all phases. The remaining respondents state that they have not noticed any intention to outsource any of the parts or phases of the process on the development and implementation of the ML models.

The respondents are split almost evenly on the topic of challenges regarding internal user acceptance of ML models. The respondents that see substantial challenges attribute this to the low explanatory power of ML-driven models and concerns on business representatives and credit officers being comfortable with the understanding and interactions of the standard approaches. However, for the latter it is recognized that specific trainings on ML methods are beneficial in this respect. The respondents that do not expect considerable challenges argue that ML models should be treated in the same manner as traditional methods as the same fundamental principles apply, where it is key to ensure that all Lines of Defense have the appropriate skills and responsibilities. Furthermore, the respondents state that existing ML applications, such as in AML, can be leveraged. The AFM explains that the techniques used to explain the results that are already available in those contexts are proving to be effective to understand the outcomes. SpA shares this sentiment and refers to Shapley values and the Lime test as techniques for model interpretability.

There exists a consensus among the respondents that ML is suitable for various areas within credit risk. For example, ESBG outlines that the opportunities for using ML models within the credit risk area and their advantages are endless. In particular for loan origination (admission), monitoring and early warning systems, the respondents are mutually in favor of applying ML. In general, the application of ML for these purposes is already being adopted by institutions far more than for IRB modeling.

To conclude

Banks are keen to use ML in the context of IRB modeling given the benefits achievable in both risk differentiation and risk quantification processes. The main reason for the limited use of ML in IRB modeling is the uncertainty in the supervisory process. The ball is currently in EBA’s court. The discussion paper and prospective set of principle-based recommendations to bridge the gap in institutional and regulatory expectations show EBA’s interest in making ML in IRB modeling a more common reality.

Zanders believes that institutions are best prepared for this transition by already applying ML to different fields, such as AML, application models and KYC. The EBA defines the enhancement of capacity to combat money laundering in the EU as one of its five main priorities for 2023 (EBA/REP/2022/20). This includes supporting the implementation of robust approaches to advance AML. Zanders anticipates that the technical EBA support in AML will spill over to IRB modeling in the coming three years. Zanders supports institutions in the application of ML in aforementioned fields, which will ensure that those institutions are adequately prepared to fully reap the rewards when ML in the context of IRB modeling is commonly accepted.

What can Zanders offer?

We combine deep credit risk modeling expertise with relevant experience in regulation and programming ​

• A Risk Advisory Team consisting of 70+ consultants with quantitative backgrounds (e.g., Econometrics and Physics)​
• Strong knowledge of credit risk models​
• Extensive experience with calibration and implementation of credit risk models​
• We offer ready-to-use rating models, Credit Risk Academy modules and expert sessions that can be tailored to you specific needs.

Interested in ML in credit risk, Credit Risk Academy, and other regulatory capital modeling services? Please feel free to contact Jimmy Tang or Elena Paniagua-Avila.

Footnotes

 ¹ CRR article 170(1)(f) and (3)(c), and RTS on AM of IRB articles 36(1)(a) and 37(1)(c)

 ² CRR articles 170(3)(a) and (4) and 171(2) and GL on PD and LGD paragraphs 21, 25, and 121

 _³ RTS on AM of IRB articles 36(1)(a) and 37(1)(c)

In this third article in the ISO 20022 series, Zanders experts Eliane Eysackers and Mark Sutton take a focused look at the Common Global Implementation Market Practice Group (CGI-MP). Explaining its role, objectives and how it has the potential to redefine what is possible in terms of taking the multi-banking cash management model to the next level. With the end-goal being a simplified, standardised, low cost, low maintenance multi-bank cash management architecture.

Who or What is the CGI-MP?

The CGI-MP was formed in October 2009, with Swift playing host for the inaugural meeting of an inclusive collaborative group of key stakeholders – banks, software vendors, corporates, national payment associations, that would redefine the competitive boundaries within the multi-banking cash management space. From these humble beginnings, the CGI-MP now has 355 members globally and has mobilized its domain expertise to create and publish implementation guidelines for the XML corporate payment message (pain.001.001.09) including an updated payment status workflow guide. The CGI-MP objective has always been crystal clear: "A corporate can use the same message structure for all their payments with all of their transaction banks reaching any payment system across the globe.”

What challenges existed with the original CGI-MP implementation guidelines?

Whilst the April 2009 ISO standards maintenance release provided the ideal opportunity to demonstrate the benefits of this initial collaboration through the inaugural implementation guidelines, the past 14 years have highlighted multiple friction points that existed around the corporate adoption of the version 3 XML payment message. So, despite the guidelines, we have witnessed significant divergence in terms of the banking communities implementation of this global financial messaging standard. The main challenges are summarized below:

• Inconsistent Payment Method Identification: Whilst the CGI-MP implementation guidelines recommended the use of standard codes, history reveals both the non-standard use of these codes and continued use of bank proprietary codes.
• Limited Adoption of Data Over-population: This was a core principle of the CGI-MP implementation guidelines which enabled the corporate community to establish a more generic core template. However, few banks actually embraced this core principle.
• Continued Focus on Unstructured Tags: Despite the guidance, the banking community has generally leveraged the unstructured tags to support local country rules like central bank reporting.
• Core References: Corporate implementations have revealed significant differences in the way the key batch and transaction references plus the payment details are supported and processed.

What is different about these new CGI-MP implementation guidelines?

The CGI-MP has taken these lessons learned from the version 3 implementations to try and remove the friction caused by the bank proprietary implementations. A core document within the implementation guidelines is Appendix B which is a supporting document that focuses on the additional specific local country rules. For example, which xml tags are used for central bank reporting in a specific country. This is important as it provides the opportunity to try and achieve a greater level of standardization around interpretation and therefore implementation of the XML payment message.

The most important difference is the ‘change of mindset’ that will be required from the banking community help deliver a win-win situation. So the CGI-MP is recommending a more prescriptive approach to the XML version 9 guidelines, which will help remove the numerous friction points that have been ‘called out’ above. Banks that follow the same ‘lift and shift’ logic to how they developed pain.001 V03, which typically followed the core logic of their own proprietary file formats will be missing a real opportunity to remove friction and accelerate implementations.

Considerations for Corporate Treasury?

The CGI-MP has now published the XML version 9 implementation guidelines, which CGI-MP member banks are now reviewing as part of their own XML version 9 service proposition. Based on the experience around the development and implementation of the original XML version 3 proposition back in 2009, banks are probably 6-9 months away from launch. However, whilst there is no requirement for the corporate community to migrate, XML version 9 presents a real possibility to:

• Remove friction between the banks.
• Simplify and standardise the XML version 3 implementation.
• Maximise the end to end benefits of structured data.
• Achieve greater bank portability.

In Summary

Considering the potential significant impact of the ‘change in mindset’ from the banking community, alignment to the CGI-MP guidelines and specifically Appendix B could become a table stake from a corporate perspective. It will be very important for the corporate community to have a very focused and structured discussion with their banking partners to help determine if the perceived benefits can materialise. And finally, as this is unproven territory, the recommendation remains on proceeding with banking partner harmonisation discussions to ensure the optimum implementation outcome.

Under FRTB regulation, PLA requires banks to assess the similarity between Front Office (FO) and Risk P&L (HPL and RTPL) on a quarterly basis. Desks which do not pass PLA incur capital surcharges or may, in more severe cases, be required to use the more conservative FRTB standardised approach (SA).​

What is the purpose of PLA?​

PLA ensures that the FO and Risk P&Ls are sufficiently aligned with one another at the desk level.​ The FO HPL is compared with the Risk RTPL using two statistical tests.​ The tests measure the materiality of any simplifications in a bank’s Risk model compared with the FO systems.​ In order to use the Internal Models Approach (IMA), FRTB requires each trading desk to pass the PLA statistical tests.​ Although the implementation of PLA begins on the date that the IMA capital requirement becomes effective, banks must provide a one-year PLA test report to confirm the quality of the model.

Which statistical measures are used?​

PLA is performed using the Spearman Correlation and the Kolmogorov-Smirnov (KS) test using the most recent 250 days of historical RTPL and HPL.​ Depending on the results, each desk is assigned a traffic light test (TLT) zone (see below), where amber desks are those which are allocated to neither red or green.​

What are the consequences of failing PLA?

Capital increase: Desks in the red zone are not permitted to use the IMA and must instead use the more conservative SA, which has higher capital requirements. ​Amber desks can use the IMA but must pay a capital surcharge until the issues are remediated.

Difficulty with returning to IMA: Desks which are in the amber or red zone must satisfy statistical green zone requirements and 12-month backtesting requirements before they can be eligible to use the IMA again.​

What are some of the key reasons for PLA failure?

Data issues: Data proxies are often used within Risk if there is a lack of data available for FO risk factors. Poor or outdated proxies can decrease the accuracy of RTPL produced by the Risk model.​ The source, timing and granularity also often differs between FO and Risk data.

Missing risk factors: Missing risk factors in the Risk model are a common cause of PLA failures. Inaccurate RTPL values caused by missing risk factors can cause discrepancies between FO and Risk P&Ls and lead to PLA failures.

Roadblocks to finding the sources of PLA failures

FO and Risk mapping: Many banks face difficulties due to a lack of accurate mapping between risk factors in FO and those in Risk. ​For example, multiple risk factors in the FO systems may map to a single risk factor in the Risk model. More simply, different naming conventions can also cause issues.​ The poor mapping can make it difficult to develop an efficient and rapid process to identify the sources of P&L differences.

Lack of existing processes: PLA is a new requirement which means there is a lack of existing infrastructure to identify causes of P&L failures. ​Although they may be monitored at the desk level, P&L differences are not commonly monitored at the risk factor level on an ongoing basis.​ A lack of ongoing monitoring of risk factors makes it difficult to pre-empt issues which may cause PLA failures and increase capital requirements.

Our approach: Identifying risk factors that are causing PLA failures

Zanders’ approach overcomes the above issues by producing analytics despite any underlying mapping issues between FO and Risk P&L data. ​Using our algorithm, risk factors are ranked depending upon how statistically likely they are to be causing differences between HPL and RTPL.​ Our metric, known as risk factor ‘alpha’, can be tracked on an ongoing basis, helping banks to remediate underlying issues with risk factors before potential PLA failures.

Zanders’ P&L attribution solution has been implemented at a Tier-1 bank, providing the necessary infrastructure to identify problematic risk factors and improve PLA desk statuses. The solution provided multiple benefits to increase efficiency and transparency of workstreams at the bank.

Conclusion

As it is a new regulatory requirement, passing the PLA test has been a key concern for many banks. Although the test itself is not considerably difficult to implement, identifying why a desk may be failing can be complicated. In this article, we present a PLA tool which has already been successfully implemented at one of our large clients. By helping banks to identify the underlying risk factors which are causing desks to fail, remediation becomes much more efficient. Efficient remediation of desks which are failing PLA, in turn, reduces the amount of capital charges which banks may incur.