Banks perform data analytics, statistical modelling, and automate financial processes using model software, making model software essential for financial risk management. 

Why banks are recently moving their model software to open-source¹: 

• Volume dependent costs: Open-source comes with flexible storage space and computation power and corresponding costs and capacity.  
• Popularity: Graduates are often trained in open-source software, whereas the pool of skilled professionals in some specific software is decreasing. 
• Customization: You can tailor it exactly to your own needs. Nothing more, nothing less. 
• Collaboration: Required level of version control and collaboration with other software available within the bank. 
• Performance: Customization and flexibility allow for enhanced performance. 

Often there is a need to reconsider the model software solution the Bank is using; open-source solutions are cost effective and can be set up in such a way that both internal and external (e.g. regulatory) requirements are satisfied. 

How Zanders can support in moving to open-source model software. 

Proper implementation of open-source model software is compliant with regulation.   

• Replication of historical situations is possible via version control, containerization and release notes within the open-source model software. Allowing third parties to replicate historical model outcomes and model development steps.   
• Governance setup via open-source ensures that everything is auditable and is released in a governed way; this can be done through releases pipelines and by setting roles and responsibilities for software users.  
• This ensures that the model goes from development to production only after governed review and approval by the correct stakeholders.  

Migration to open-source software is achievable. 

• The open-source model software is first implemented including governance (release processes and roles and responsibilities).  
• Then all current (data and) models are refactored from the current model software to the new one.  
• Only after an extensive period of successful (shadow) testing the migration to the new model software is completed.  

Zanders has a wealth of experience performing these exercises at several major banks, often in parallel to (or combined with) model change projects. Hence, if you have interest, we will be happy to share some further insights into our latest experiences/solutions in this specific area.  

Therefore, we welcome you to reach out to Ward Broeders (Senior Manager).

The CLS system was established back in 2002 and since then, the FX market has grown significantly. Therefore, there is a high demand from corporates to leverage CLS to improve corporate treasury efficiency.

In this article we shed some light on the possible technical solutions in SAP Treasury to implement CLS in the corporate treasury operations. This includes CLS deal capture, limit utilization implications in Credit risk analyzer, and changes in the correspondence framework of SAP TRM.

Technical solution in SAP Treasury
There is no SAP standard solution for CLS as such. However, SAP standard functionality can be used to cover major parts of the CLS solution. The solution may vary depending on the existing functionality for hedge management/accounting and limit management as well as the technical landscape accounting for SAP version and SWIFT connectivity.

Below is a simplified workflow of CLS deal processing:

The proposed solution may be applicable for a corporate using SAP TRM (ECC to S/4HANA), having Credit risk analyzer activated and using SWIFT connection for connectivity with the banks.

Capturing CLS FX deals
There are a few options on how to register the FX deal as a CLS deal, with two described below:

Option 1: CLS Business partner – a replica of your usual business partner (BP) which would have CLS BIC code and complete settlement instructions.
Option 2: CLS FX product type/transaction type – a replica of normal FX SPOT, FX FORWARD or FX SWAP product type/transaction type.

Each option has pros and cons and may be applied as per a client technical specific.

FX deals trading and capturing may be executed via SAP Trade Platform Integration (TPI), which would improve the processing efficiency, but development may still be required depending on characteristics of the scope of FX dealing. In particular, the currency, product type, counterparty scope and volume of transactions would drive whether additional development is required, or whether standard mapping logic can be used to isolate CLS deals.

For the scenarios where a custom solution is required to convert standard FX deals into CLS FX deals during its creation, a custom program could be created that includes an additional mapping table to help SAP determine CLS eligible deals. The bespoke mapping table could help identify CLS eligibility based on the below characteristics:

• Counterparty
• Currency Pair
• Product Type (Spot, Forward, SWAP)

Correspondence framework
Once CLS deal is captured in SAP TRM, it needs to be counter-confirmed with the trading counterparty and with CLS Bank. Three new types of correspondence need to be configured:

• MT300 with CLS specifics to be used to communicate with the trading counterparty;
• MT304 to communicate with CLS Custody service;
• SWIFT MT396 to get the matching status from CLS bank.

Credit Risk Analyzer (CRA)
FX CLS deals do not bring settlement exposure, thus CLS deals need to be exempt from the settlement risk utilization. Configuration of the limit characteristics must include either business partner number (for CLS Business Partner) or transaction type (for CLS transaction type). This will help determine the limits without FX CLS deals.

No automatic limits creation should be allowed for the respective limit type; this will disable a settlement limit creation based on CLS deal capture in SAP.
CLS Business partner setting must be done with ‘parent <-> subsidiary’ relationship with the regular business partner. This is required to keep a single credit limit utilization and having FX deals being done with two business partners.

Deal execution
Accounting for CLS FX deals is normally the same as for regular FX deals, though it depends on the corporate requirements. We do not see any need for a separate FX unrealized result treatment for CLS deals.

However, settlement of CLS deals is different and standard settlement instructions of CLS deals vary from normal FX deals.

Either the bank’s virtual accounts or separate house bank accounts are opened to settle CLS FX deals.

Since CLS partner performs the net settlement on-behalf of a corporate there is no need to generate payment request for every CLS deal separately. Posting to the bank’s CLS clearing account with cash flow postings (TBB1) is sufficient at this level.

The following day the bank statement will clear the postings on the CLS settlement account on a net basis based on the total amount and posting date.

Cash Management
A liquidity manager needs to know the net result of the CLS deals in advance to replenish the CLS bank account in case the net settlement amount for CLS deal is negative. In addition, the funds would need to be transmitted between the house bank accounts either manually or automatically, with cash concentration requiring transparency on the projected cash position.

The solution may require extra settings in the cash management module with CLS bank accounts to be added to specific groupings.

Conclusion
Designing a CLS solution in SAP requires deep understanding of a client’s treasury operations, bank account structure and SAP TMS specifics. Together with a client and based on the unique business landscape, we review the pros and cons of possible solutions and help choosing the best one. Eventually we can design and implement a solution that makes treasury operations more efficient and transparent.

Our corporate clients are requesting our support with design and implementation of Continuous Linked Settlement (CLS) solutions for FX settlements in their SAP Treasury system. If you are interested, please do not hesitate to contact us.