This article highlights key points mentioned in our whitepaper: Treasury 4.x - The age of productivity, performance and steering. You can download the full whitepaper here.

Summary: Resilience amid uncertainty 

Tectonic geopolitical shifts leading to fragile supply chains, inflation, volatility on financial markets and adoption of  business models, fundamental demographic changes leading to capacity and skill shortages on relevant labor markets – a perpetual stream of disruption is pushing businesses to their limits, highlighting vulnerabilities in operations, challenging productivity, and leading to damaging financial consequences. Never has there been a greater need for CFOs to call on their corporate treasury for help steering their business through the persistent market and economic volatility. This is accelerating the urgency to advance the role of treasury to perform this broadened mandate. This is where Treasury 4.x steps in.  

Productivity. Performance. Steering.  

Treasury deserves a well-recognized place at the CFO's table - not at the edge, but right in the middle. Treasury 4.x recognizes the measurable impact treasury has in navigating uncertainty and driving corporate success. It also outlines what needs to happen to enable treasury to fulfil this strategic potential, focusing on three key areas:  

1. Increasing productivity: Personnel, capital, and data – these three factors of production are the source of sizeable opportunities to drive up efficiency, escape an endless spiral of cost-cutting programs and maintain necessary budgets. This can be achieved by investing in highly efficient, IT-supported decision-making processes and further amplified with analytics and AI. Another option is outsourcing activities that require highly specialized expert knowledge but don’t need to be constantly available. It’s also possible to reduce the personnel factor of production through substitution with the data factor of production (in this context knowledge) and the optimization of the capital factor of production.  We explain this in detail in Chapter 4 – Unlocking the power of productivity.  

2. Performance enhancements: Currency and commodity price risk management, corporate financing, interest rate risk management, cash and liquidity management and, an old classic, working capital management – it’s possible to make improvements across almost all treasury processes to achieve enhanced financial results. Working capital management is of particular importance as it’s synonymous with the focus on cash and therefore, the continuous optimization of processes which are driving liquidity. We unpick each of these performance elements in Chapter 5 – The quest for peak performance.  

3. Steering success: Ideologically, the door has opened for the treasurer into the CFO’s room. But many uncertainties remain around how this role and relationship will work in practice, with persistent questions around the nature and scope of the function’s involvement in corporate management and decision-making. In this document, we outline the case for making treasury’s contribution to decision-making parameters available at an early stage, before investment and financing decisions are made. The concept of Enterprise Liquidity Performance Management (ELPM) provides a more holistic approach to liquidity management and long-needed orientation. This recognizes and accounts for cross-function dependencies and how these impact the balance sheet, income statement and cash flow. Also, the topic of company ratings bears further opportunities for treasury involvement and value-add: through optimization of both tactical and strategic measures in processes such as financing, cash management, financial risk management and working capital management. These are the core subjects we debate in Chapter 6 – The definition of successful steering.  

The foundations for a more strategic treasury have been in place for years as part of a concept which is named Treasury 4.0 . But now, as businesses continue to face challenges and uncertainty, it’s time to pick up the pace of change. And to do this corporate treasury requires a new roadmap.  

Whether a corporate operates through a decentralized model, shared service center or even global business services model, identifying which invoices a customer has paid and in some cases, a more basic "who has actually paid me" creates a drag on operational efficiency. Given the increased focus on working capital efficiencies, accelerating cash application will improve DSO (Days Sales Outstanding) which is a key contributor to working capital. As the industry adoption of ISO 20022 XML continues to build momentum, Zanders experts Eliane Eysackers and Mark Sutton provide some valuable insights around why the latest industry adopted version of XML from the 2019 ISO standards maintenance release presents a real opportunity to drive operational and financial efficiencies around the reconciliation domain.   

A quick recap on the current A/R reconciliation challenges

Whilst the objective will always be 100% straight-through reconciliation (STR), the account reconciliation challenges fall into four distinct areas:

1. Data Quality

• Partial payment of invoices.
• Single consolidated payment covering multiple invoices.
• Truncated information during the end to end payment processing.
• Separate remittance information (typically PDF advice via email).

2. In-country Payment Practices and Payment Methods

• Available information supported through the in-country clearing systems.

• Different local clearing systems – not all countries offer a direct debit capability.

• Local market practice around preferred collection methods (for example the Boleto in Brazil).

• ‘Culture’ – some countries are less comfortable with the concept of direct debit collections and want full control to remain with the customer when it comes to making a payment.

3. Statement File Format

• Limitations associated with some statement reporting formats – for example the Swift MT940 has approximately 20 data fields compared to the ISO XML camt.053 bank statement which contains almost 1,600 xml tags.

• Partner bank capability limitations in terms of the supported statement formats and how the actual bank statements are generated. For example, some banks still create a camt.053 statement using the MT940 as the data source. This means the corporates receives an xml MT940!

• Market practice as most companies have historically used the Swift MT940 bank statement for reconciliation purposes, but this legacy Swift MT first mindset is now being challenged with the broader industry migration to ISO 20022 XML messaging.

4. Technology & Operations

• Systems limitations on the corporate side which prevent the ERP or TMS consuming a camt.053 bank statement.

• Limited system level capabilities around auto-matching rules based logic.

• Dependency on limited IT resources and budget pressures for customization.

• No global standardized system landscape and operational processes.

How can ISO20022 XML bank statements help accelerate and elevate reconciliation performance?

At a high level, the benefits of ISO 20022 XML financial statement messaging can be boiled down into the richness of data that can be supported through the ISO 20022 XML messages. You have a very rich data structure, so each data point should have its own unique xml field.  This covers not only more structured information around the actual payment remittance details, but also enhanced data which enables a higher degree of STR, in addition to the opportunity for improved reporting, analysis and importantly, risk management.

Enhanced Data

• Structured remittance information covering invoice numbers, amounts and dates provides the opportunity to automate and accelerate the cash application process, removing the friction around manual reconciliations and reducing exceptions through improved end to end data quality.
• Additionally, the latest camt.053 bank statement includes a series of key references that can be supported from the originator generated end to end reference, to the Swift GPI reference and partner bank reference.
• Richer FX related data covering source and target currencies as well as applied FX rates and associated contract IDs. These values can be mapped into the ERP/TMS system to automatically calculate any realised gain/loss on the transaction which removes the need for manual reconciliation.
• Fees and charges are reported separately, combined a rich and very granular BTC (Bank Transaction Code) code list which allows for automated posting to the correct internal G/L account.
• Enhanced related party information which is essential when dealing with organizations that operate an OBO (on-behalf-of) model. This additional transparency ensures the ultimate party is visible which allows for the acceleration through auto-matching.
• The intraday (camt.052) provides an acceleration of this enhanced data that will enable both the automation and acceleration of reconciliation processes, thereby reducing manual effort. Treasury will witness a reduction in credit risk exposure through the accelerated clearance of payments, allowing the company to release goods from warehouses sooner. This improves customer satisfaction and also optimizes inventory management. Furthermore, the intraday updates will enable efficient management of cash positions and forecasts, leading to better overall liquidity management.

Enhanced Risk Management

• The full structured information will help support a more effective and efficient compliance, risk management and increasing regulatory process. The inclusion of the LEI helps identify the parent entity. Unique transaction IDs enable the auto-matching with the original hedging contract ID in addition to credit facilities (letters of credit/bank guarantees).

In Summary

The ISO 20022 camt.053 bank statement and camt.052 intraday statement provide a clear opportunity to redefine best in class reconciliation processes. Whilst the camt.053.001.02 has been around since 2009, corporate adoption has not matched the scale of the associated pain.001.001.03 payment message. This is down to a combination of bank and system capabilities, but it would also be relevant to point out the above benefits have not materialised due to the heavy use of unstructured data within the camt.053.001.02 message version.

The new camt.053.001.08 statement message contains enhanced structured data options, which when combined with the CGI-MP (Common Global Implementation – Market Practice) Group implementation guidelines, provide a much greater opportunity to accelerate and elevate the reconciliation process. This is linked to the recommended prescriptive approach around a structured data first model from the banking community.

Finally, linked to the current Swift MT-MX migration, there is now agreement that up to 9,000 characters can be provided as payment remittance information. These 9,000 characters must be contained within the structured remittance information block subject to bilateral agreement within the cross border messaging space. Considering the corporate digital transformation agenda – to truly harness the power of artificial intelligence (AI) and machine learning (ML) technology – data – specifically structured data, will be the fuel that powers AI. It’s important to recognize that ISO 20022 XML will be an enabler delivering on the technologies potential to deliver both predictive and prescriptive analytics. This technology will be a real game-changer for corporate treasury not only addressing a number of existing and longstanding pain-points but also redefining what is possible.

The corporate treasury agenda continues to focus on cash visibility, liquidity centralization, bank/bank account rationalization, and finally digitization to enable greater operational and financial efficiencies. Digital transformation within corporate treasury is a must have, not a nice to have and with technology continuing to evolve, the potential opportunities to both accelerate and elevate performance has just been taken to the next level with ISO 20022 becoming the global language of payments. In this 6^th article in the ISO 20022 XML series, Zanders experts Fernando Almansa, Eliane Eysackers and Mark Sutton provide some valuable insights around why this latest global industry move should now provide the motivation for corporate treasury to consider a cash management RFP (request for proposal) for its banking services.

Why Me and Why Now?

These are both very relevant important questions that corporate treasury should be considering in 2024, given the broader global payments industry migration to ISO 20022 XML messaging. This goes beyond the Swift MT-MX migration in the interbank space as an increasing number of in-country RTGS (real-time gross settlement) clearing systems are also adopting ISO 20022 XML messaging. Swift are currently estimating that by 2025, 80% of the domestic high value clearing RTGS volumes will be ISO 20022-based with all reserve currencies either live or having declared a live date. As more local market infrastructures migrate to XML messaging, there is the potential to provide richer and more structured information around the payment to accelerate and elevate compliance and reconciliation processes as well as achieving a more simplified and standardized strategic cash management operating model.

So to help determine if this really applies to you, the following questions should be considered around existing process friction points:

1. Is your current multi-banking cash management architecture simplified and standardised?
2. Is your account receivables process fully automated?
3. Is your FX gain/loss calculations fully automated?
4. Have you fully automated the G/L account posting?
5. Do you have a standard ‘harmonized’ payments message that you send to all your banking partners?

If the answer is yes to all the above, then you are already following a best-in-class multi-banking cash management model. But if the answer is no, then it is worth reading the rest of this article as we now have a paradigm shift in the global payments landscape that presents a real opportunity to redefine best in class.

What is different about XML V09?

Whilst structurally, the XML V09 message only contains a handful of additional data points when compared with the earlier XML V03 message that was released back in 2009, the key difference is around the changing mindset from the CGI-MP (Common Global Implementation – Market Practice) Group¹ which is recommending a more prescriptive approach to the banking community around adoption of its published implementation guidelines. The original objective of the CGI-MP was to remove the friction that existed in the multi-banking space as a result of the complexity, inefficiency, and cost of corporates having to support proprietary bank formats. The adoption of ISO 20022 provided the opportunity to simplify and standardize the multi-banking environment, with the added benefit of providing a more portable messaging structure. However, even with the work of the CGI-MP group, which produced and published implementation guidelines back in 2009, the corporate community has encountered a significant number of challenges as part of their adoption of this global financial messaging standard.

The key friction points are highlighted below:

Diagram 1: Key friction points encountered by the corporate community in adopting XML V03

The highlighted friction points have resulted in the corporate community achieving a sub-optimal cash management architecture. Significant divergence in terms of the banks’ implementation of this standard covers a number of aspects, from non-standard payment method codes and payment batching logic to proprietary requirements around regulatory reporting and customer identification. All of this translated into additional complexity, inefficiency, and cost on the corporate side.

However, XML V09 offers a real opportunity to simplify, standardise, accelerate and elevate cash management performance where the banking community embraces the CGI-MP recommended ‘more prescriptive approach’ that will help deliver a win-win situation. This is more than just about a global standardised payment message, this is about the end to end cash management processes with a ‘structured data first’ mindset which will allow the corporate community to truly harness the power of technology.

What are the objectives of the RFP?

The RFP or RFI (request for information) process will provide the opportunity to understand the current mindset of your existing core cash management banking partners. Are they viewing the MT-MX migration as just a compliance exercise. Do they recognize the importance and benefits to the corporate community of embracing the recently published CGI-MP guidelines? Are they going to follow a structured data first model when it comes to statement reporting? Having a clearer view in how your current cash management banks are thinking around this important global change will help corporate treasury to make a more informed decision on potential future strategic cash management banking partners. More broadly, the RFP will provide an opportunity to ensure your core cash management banks have a strong strategic fit with your business across dimensions such as credit commitment, relationship support to your company and the industry you operate, access to senior management and ease of doing of business. Furthermore, you will be in a better position to achieve simplification and standardization of your banking providers through bank account rationalization combined with the removal of non-core partner banks from your current day to day banking operations.

In Summary

The Swift MT-MX migration and global industry adoption of ISO 20022 XML should be viewed as more than just a simple compliance change. This is about the opportunity to redefine a best in class cash management model that delivers operational and financial efficiencies and provides the foundation to truly harness the power of technology.

Zanders Transfer Pricing Suite is an innovative, cloud-based solution designed for companies looking to automate the Transfer Pricing compliance of financial transactions. With over five years of experience and trusted by more than 60 multinational corporations, the platform is the market-leading solution for financial transactions Transfer Pricing. On March 31, 2023, Zanders and Royal Philips jointly presented the conference "How Philips Automated Its Transfer Pricing Process for Group Financing" at the DACT (Dutch Association of Corporate Treasurers) Treasury Fair 2023.

Context
The publication of Chapter X of Financial Transactions by the OECD, as well as its incorporation into the 2022 OECD Transfer Pricing Guidelines, has led to an increased scrutiny by tax authorities. Consequently, transfer pricing for financial transactions, such as intra-group loans, guarantees, cash pools, and in-house banks, has become a critical focus for treasury and tax departments.

ZANDERS TRANSFER PRICING SOLUTION

As compliance with Transfer Pricing regulations gains greater significance, many companies find that the associated analyses consume excessive time and resources from their in-house tax and treasury departments. Several struggle to automate the end-to-end process, from initiating intercompany loans to determining the arm's length interest, recording the loans in their Treasury Management System (TMS), and storing the Transfer Pricing documentation.

Since 2018, Zanders Transfer Pricing Solution has supported multinational corporations in automating their Transfer Pricing compliance processes for financial transactions.

ROYAL PHILIPS CASE STUDY

Managing over 80 intercompany loans annually and with a wide geographical scope, Royal Philips faced the challenge of complying with their Transfer Pricing obligations. During the conference, Joris Van Mierlo, Corporate Finance Manager at Philips, detailed how Royal Philips implemented a fully integrated solution to determine and record the arm's length interest rates applicable to its intra-group loans.

Additionally, business partners are essential in SAP for recording information related to securities issues, such as shares and funds. 

The SAP Treasury Business Partner (BP) serves as a fundamental treasury master data object, utilized for managing relationships with both external and internal counterparties across a variety of financial transactions; including FX, MM, derivatives, and securities. The BP master data encompasses crucial details such as names, addresses, contact information, bank details, country codes, credit ratings, settlement information, authorizations, withholding tax specifics, and more. 

Treasury BPs are integral and mandatory components within other SAP Treasury objects, including financial instruments, cash management, in-house cash, and risk analysis. As a result, the proper design and accurate creation of BPs are pivotal to the successful implementation of SAP Treasury functionality. The creation of BPs represents a critical step in the project implementation plan. 

Therefore, we aim to highlight key specifics for professionally designing BPs and maintaining them within the SAP Treasury system. The following section will outline the key focus areas where consultants need to align with business users to ensure the smooth and seamless creation and maintenance of BPs. 

Structure of the BPs: 

The structure of BPs may vary depending on a corporation's specific requirements. Below is the most common structure of treasury BPs: 

Group BP – represents a parent company, such as the headquarters of a bank group or corporate entity. Typically, this level of BP is not directly involved in trading processes, meaning no deals are created with this BP. Instead, these BPs are used for: a. reflecting credit ratings, b. limiting utilization in the credit risk analyzer, c. reporting purposes, etc. 

Transactional BP – represents a direct counterparty used for booking deals. Transactional BPs can be divided into two types: 

   - External BPs – represent banks, financial institutions, and security issuers. 

   - Internal BPs – represent subsidiaries of a company. 

Naming convention of BPs 

It is important to define a naming convention for the different types of BPs, and once defined, it is recommended to adhere to the blueprint design to maintain the integrity of the data in SAP. 

Group BP ID: Should have a meaningful ID that most business users can understand. Ideally, the IDs should be of the same length. For example: ABN AMRO Group = ABNAMR or ABNGRP, Citibank Group = CITGRP or CITIBNK. 

External BP ID: Should also have a meaningful ID, with the addition of the counterparty's location. For example: ABN AMRO Amsterdam – ABNAMS, Citibank London – CITLON, etc. 

Internal BP ID: The main recommendation here is to align the BP ID with the company code number. For example, if the company code of the subsidiary is 1111, then its BP ID should be 1111. However, it is not always possible to follow this simple rule due to the complexity of the ERP and SAP Treasury landscape. Nonetheless, this simple rule can help both business and IT teams find straightforward solutions in SAP Treasury. 

The length of the BP IDs should be consistent within each BP type. 

Maintenance of Treasury BPs 

1. BP Creation: 

Business partners are created in SAP using the t-code BP. During the creation process, various details are entered to establish the master data record. This includes basic information such as name, address, contact details, as well as specific financial data such as bank account information, settlement instructions, WHT, authorizations, credit rating, tax residency country, etc. 

Consider implementing an automated tool for creating Treasury BPs. We recommend leveraging SAP migration cockpit, SAP scripting, etc. At Zanders we have a pre-developed solution to create complex Treasury BPs which covers both SAP ECC and most recent version of SAP S/4 HANA. 

2. BP Amendment: 

Regular updates to BP master data are crucial to ensure accuracy. Changes in addresses, contact information, or payment details should be promptly recorded in SAP. 

3. BP Release: 

Treasury BPs must be validated before use. This validation is carried out in SAP through a release workflow procedure. We highly recommend activating such a release for the creation and amendment of BPs, and nominating a person to release a BP who is not authorized to create/amend a BP.  
BP amendments are often carried out by the Back Office or Master Data team, while BP release is handled by a Middle Office officer.  

4. BP Hierarchies: 

Business partners can have relationships as described, and the system allows for the maintenance of these relationships, ensuring that accurate links are established between various entities involved in financial transactions. 

5. Alignment: 

During the Treasury BP design phase, it is important to consider that BPs will be utilized by other teams in a form of Vendors, Customers, or Employees. SAP AP/AR/HR teams may apply different conditions to a BP, which can have an impact on Treasury functions. For instance, the HR team may require bank details of employees to be hidden, and this requirement should be reflected in the Treasury BP roles. Additionally, clearing Treasury identification types or making AP/AR reconciliation GL accounts mandatory for Treasury roles could also be necessary.  

Transparent and effective communication, as well as clear data ownership, are essential in defining the design of the BPs. 

Conclusion 

The design and implementation of BPs require expertise and close alignment with treasury business users to meet all requirements and consider other SAP streams.  

At Zanders, we have a strong team of experienced SAP consultants who can assist you in designing BP master data, developing tools to create/amend the BPs meeting strict treasury segregation of duties and the clients IT rules and procedures. 

But the adoption of ISO 20022 XML messaging goes beyond SWIFT’s adoption in the interbank financial messaging space – SWIFT are currently estimating that by 2025, 80% of the RTGS (real time gross settlement) volumes will be ISO 20022 based with all reserve currencies either live or having declared a live date. What this means is that ISO 20022 XML is becoming the global language of payments. In this fourth article in the ISO 20022 series, Zanders experts Eliane Eysackers and Mark Sutton provide some valuable insights around what the version 9 payment message offers the corporate community in terms of richer functionality.  

A quick recap on the ISO maintenance process?

So, XML version 9. What we are referencing is the pain.001.001.09 customer credit transfer initiation message from the ISO 2019 annual maintenance release. Now at this point, some people reading this article will be thinking they are currently using XML version 3 and now we talking about XML version 9. The logical question is whether version 9 is the latest message and actually, we expect version 12 to be released in 2024. So whilst ISO has an annual maintenance release process, the financial industry and all the associated key stakeholders will be aligning on the XML version 9 message from the ISO 2019 maintenance release. This version is expected to replace XML version 3 as the de-facto standard in the corporate to bank financial messaging space.

What new functionality is available with the version 9 payment message?

Comparing the current XML version 3 with the latest XML version 9 industry standard, there are a number of new tags/features which make the message design more relevant to the current digital transformation of the payment’s ecosystem. We look at the main changes below:

• Proxy: A new field has been introduced to support a proxy or tokenisation as its sometimes called. The relevance of this field is primarily linked to the new faster payment rails and open banking models, where consumers want to provide a mobile phone number or email address to mask the real bank account details and facilitate the payment transfer. The use of the proxy is becoming more widely used across Asia with the India (Unified Payments Interface) instant payment scheme being the first clearing system to adopt this logic. With the rise of instant clearing systems across the world, we are starting to see a much greater use of proxy, with countries like Australia (NPP), Indonesia (BI-FAST), Malaysia (DuitNow), Singapore (FAST) and Thailand (Promptpay) all adopting this feature.
• The Legal Entity Identifier (LEI): This is a 20-character, alpha-numeric code developed by the ISO. It connects to key reference information that enables clear and unique identification of legal entities participating in financial transactions. Each LEI contains information about an entity’s ownership structure and thus answers the questions of 'who is who’ and ‘who owns whom’. Simply put, the publicly available LEI data pool can be regarded as a global directory, which greatly enhances transparency in the global marketplace. The first country to require the LEI as part of the payment data is India, but the expectation is more local clearing system’s will require this identifier from a compliance perspective.
• Unique End-to-end Transaction Reference (commonly known as a UETR): This is a string of 36 unique characters featured in all payment instruction messages carried over the SWIFT network. UETRs are designed to act as a single source of truth for a payment and provide complete transparency for all parties in a payment chain, as well as enable functionality from SWIFT gpi (global payments innovation)¹, such as the payment Tracker.
• Gender neutral term: This new field has been added as a name prefix.
• Requested Execution Date: The requested execution date now includes a data and time option to provide some additional flexibility.
• Structured Address Block: The structured address block has been updated to include the Building Name.

In Summary

Whilst there is no requirement for the corporate community to migrate onto the XML version 9 message, corporate treasury should now have the SWIFT ISO 20022 XML migration on their own radar in addition to understanding the broader global market infrastructure adoption of ISO 20022. This will ensure corporate treasury can make timely and informed decisions around any future migration plan.

Notes:

1. SWIFT gpi is a set of standards and rules that enable banks to offer faster, more transparent, and more reliable cross-border payments to their customers.

Carbon offset processes are currently dominated by private actors providing legitimacy for the market. The two largest of these, Verra and Gold Standard, provide auditing services, carbon registries and a marketplace to sell carbon offsets, making them ubiquitous in the whole process. Due to this opacity and centralisation, the business models of the existing companies was criticised regarding its validity and the actual benefit for climate action. By buying an offset in the traditional manner, the buyer must place trust in these players and their business models. Alternative solutions that would enhance the transparency of the process as well as provide decentralised marketplaces are thus called for.

The conventional process

Carbon offsets are certificates or credits that represent a reduction or removal of greenhouse gas emissions from the atmosphere. Offset markets work by having companies and organizations voluntarily pay for carbon offsetting projects. Reasons for partaking in voluntary carbon markets vary from increased awareness of corporate responsibility to a belief that emissions legislation is inevitable, and it is thus better to partake earlier.

Some industries also suffer prohibitively expensive barriers for lowering their emissions, or simply can’t reduce them because of the nature of their business. These industries can instead benefit from carbon offsets, as they manage to lower overall carbon emissions while still staying in business. Environmental organisations run climate-friendly projects and offer certificate-based investments for companies or individuals who therefore can reduce their own carbon footprint. By purchasing such certificates, they invest in these projects and their actual or future reduction of emissions. However, on a global scale, it is not enough to simply lower our carbon footprint to negate the effects of climate change. Emissions would in practice have to be negative, so that even a target of 1,5-degree Celsius warming could be met. This is also remedied by carbon credits, as they offer us a chance of removing carbon from the atmosphere. In the current process, companies looking to take part in the offsetting market will at some point run into the aforementioned behemoths and therefore an opaque form of purchasing carbon offsets.

The blockchain approach

A blockchain is a secure and decentralised database or ledger which is shared among the nodes of a computer network. Therefore, this technology can offer a valid contribution addressing the opacity and centralisation of the traditional procedure. The intention of the first blockchain approaches were the distribution of digital information in a shared ledger that is agreed on jointly and updated in a transparent manner. The information is recorded in blocks and added to the chain irreversibly, thus preventing the alteration, deletion and irregular inclusion of data.

In the recent years, tokenization of (physical) assets and the creation of a digital version that is stored on the blockchain gained more interest. By utilizing blockchain technology, asset ownership can be tokenized, which enables fractional ownership, reduces intermediaries, and provides a secure and transparent ledger. This not only increases liquidity but also expands access to previously illiquid assets (like carbon offsets). The blockchain ledger allows for real-time settlement of transactions, increasing efficiency and reducing the risk of fraud. Additionally, tokens can be programmed to include certain rules and restrictions, such as limiting the number of tokens that can be issued or specifying how they can be traded, which can provide greater transparency and control over the asset.

Blockchain-based carbon offset process

The tokenisation process for carbon credits begins with the identification of a project that either captures or helps to avoid carbon creation. In this example, the focus is on carbon avoidance through solar panels. The generation of solar electricity is considered an offset, as alternative energy use would emit carbon dioxide, whereas solar power does not.

The solar panels provide information regarding their electricity generation, from which a figure is derived that represents the amount of carbon avoided and fed into a smart contract. A smart contract is a self-executing application that exist on the blockchain and performs actions based on its underlying code. In the blockchain-based carbon offset process, smart contracts convert the different tokens and send them to the owner’s wallet. The tokens used within the process are compliant with the ERC-721 Non-Fungible Token (NFT) standard, which represents a unique token that is distinguishable from others and cannot be exchanged for other units of the same asset. A practical example is a work of art that, even if replicated, is always slightly different.

In the first stage of the process, the owner claims a carbon receipt, based on the amount of carbon avoided by the solar panel. Thereby the aggregated amount of carbon avoided (also stored in a database just for replication purposes) is sent to the smart contract, which issues a carbon receipt of the corresponding figure to the owner. Carbon receipts can further be exchanged for a uniform amount of carbon credits (e.g. 5 kg, 10 kg, 15 kg) by interacting with the second smart contract. Carbon credits are designed to be traded on the decentralised marketplace, where the price is determined by the supply and demand of its participants. Ultimately, carbon credits can be exchanged for carbon certificates indicating the certificate owner and the amount of carbon offset. Comparable with a university diploma, carbon certificates are tied to the address of the owner that initiated the exchange and are therefore non-tradable. Figure 1 illustrates the process of the described blockchain-based carbon offset solution:

Figure 1: Process flow of a blockchain-based carbon offset solution

Conclusion

The outlined blockchain-based carbon offset process was developed by Zanders’ blockchain team in a proof of concept. It was designed as an approach to reduce dependence on central players and a transparent method of issuing carbon credits. The smart contracts that the platform interacts with are implemented on the Mumbai test network of the public Polygon blockchain, which allows for fast transaction processing and minimal fees. The PoC is up and running, tokenizing the carbon savings generated by one of our colleagues photovoltaic system, and can be showcased in a demo. However, there are some clear optimisations to the process that should be considered for a larger scale (commercial) setup.

If you're interested in exploring the concept and benefits of a blockchain-based carbon offset process involving decentralised issuance and exchange of digital assets, or if you would like to see a demo, you can contact Robert Richter or Justus Schleicher.

Today, we engage in a conversation with Brecht van den Driessche, a new addition to the Zanders team, to explore his motivations for joining Zanders and his vision for the future of risk management.

Q: Why did you choose Zanders?

A: I've been familiar with Zanders for over a decade, and what has consistently impressed me is the professionalism and deep expertise in Risk Management demonstrated by its people. Consultancy is inherently a people-centric business, and the combination of professionalism with an engaging and enjoyable working environment was a key factor in my decision to join the Zanders team.

Q: What are your focus areas and goals for the short term and long term?

A: The landscape of expectations for Risk Managers and their regulators is rapidly evolving. Recent events such as the collapse of Silicon Valley Bank and the takeover of Credit Suisse by UBS have highlighted the critical importance of proper Risk Management. Financial institutions must invest in a centralized risk function and supporting systems to enhance transparency and real-time Risk Management. Worldwide, there is a clear trend among banks to centralize data, improve Risk Management systems, and perform more frequent, granular, and standardized risk calculations and disclosures. Regulators are increasingly pushing banks to move away from spreadsheets and manage their financial risks with professional, often vendor-based systems. As a result, banks are moving away from legacy systems and heavily investing in new Risk Management Systems.

My primary focus is to assist our customers in embracing further digitalization to maximize the benefits of these investments. This includes strategic benchmarking, optimization, selection, and the implementation of fit-for-purpose Risk Management systems. To achieve this, we collaborate closely with a select group of world-leading suppliers of risk technology.

The ultimate goal is for Zanders to become the go-to expert for our clients, providing them with robust Risk Management systems to effectively manage financial risks and make informed decisions.

Q: How were your first weeks at Zanders?

A: Right from day one, I felt the positive energy and warmth that characterizes the Zanders team. Simultaneously, around 20 new colleagues embarked on their Zanders journeys across Europe, and the onboarding process was exceptionally smooth. I've already had the pleasure of meeting many colleagues, clients, and partners, and I am genuinely convinced that my decision to join Zanders was the perfect career move.

Q: Anything you want to share with the outside world about this career move?

A: If you're curious about our ambitions and how we can help you achieve yours, don't hesitate to reach out. Drop me a message, and let's connect.

In a world of ever-evolving risks and escalating expectations in risk management, Zanders plays a pivotal role in helping organizations navigate these challenges, propelling them toward success. With our unwavering focus on professionalism, expertise, and a commitment to embracing digitalization, we stand as a trusted partner for those in the finance industry. To learn more about us, please visit our About Zanders page.

SWIFT now supports the exchange of ISO 20022 XML or MX message via the so-called FINplus network. In parallel, the legacy MT format messages remain to be exchanged over the ‘regular’ FIN network; The MT flow for message categories 1 (customer payments), 2 (FI transfers) and 9 (statements) through the FIN network will be decommissioned per November 2025. 

As such, between March 2023 and November 2025, financial institutions need to be able to receive and process MX messages through FINplus on the inbound side, and optionally send MX messages or MT messages for outbound messaging. After that period, only MX will be allowed.  

CBPR+ and HVPS+ 

Another important aspect of the MX migration is the development of the CBPR+ and HVPS+ specifications within the ISO20022 XML standard. These specifications dictate how an XML message should be populated in terms of data and field requirements for Cross Border Payments (CBPR+) and Domestic High Value Payments (HVPS+). Note that HVPS+ refers to domestic RTGS clearing systems and a number of countries are in the process of making the domestic clearing systems native ISO20022 XML-compliant.  

Impact for Corporates 

As of today, there should be no immediate need for corporates to change. However, it is advised to start assessing impact and to start planning for change if needed. We give you some cases to consider: 

1. A corporate currently exchanging e.g. MT101/MT103/MT210 messages towards its house bank via SWIFT FIN Network to make cross border payments, e.g. employing a SWIFT Service Bureau or an Alliance connection. This flow will cease to work after November 2025. If this flow is relevant to your company, it needs attention to be replaced. 
2. Another case is where, for example, an MT101 is exchanged with a house bank as a file over the FileAct network. Now it depends purely on the house bank’s capabilities to continue supporting this flow after 2025; it could offer a service to do a remapping of your MT message into an MX. This needs to be checked with the house banks. 
3. The MT940 message flow from the house bank via FIN also requires replacement. 
4. With respect to the MT940 file flow from house bank via FileAct, we expect little impact as we think most banks will continue supporting the MT940 format exchange as files. We do recommend to check with your house bank to be sure. 
5. High Value Payments for Domestic Japanese Yen using Zengin format; the BOJ-NET RTGS clearing system has already completed the migration to ISO20022 XML standard. Check with your house bank when the legacy payment format will become unsupported and take action accordingly.  

These were just some examples and should not be considered an exhaustive list.  

In addition, moving to the ISO20022 XML standard can also provide some softer benefits. We discussed this in a previously published article. 

Impact on your SAP implementation 

So you have determined that the MT/MX migration has impact and that remediating actions need to be taken. What does that look like in SAP? 

First of all, it is very important to onboard the bank to support you with your change. Most typically, the bank needs to prepare its systems to be able to receive a new payment file format from your end. It is good practice to first test the payment file formatting and receive feedback from the banks implementation manager before going live with it.  

On the incoming side, it is advisable to first request a number of production bank statements in e.g. the new CAMT.053 format, which can be analyzed and loaded in your test system. This will form a good basis for understanding the changes needed in bank statement posting logic in the SAP system.  

PAYMENTS 

In general, there are two ways of generating payment files in SAP. The classical one is via a payment method linked to a Payment Medium Workbench (PMW) format and a Data Medium Exchange (DME) tree. This payment method is then linked to your open items which can be processed with the payment run. The payment run then outputs the files as determined in your DME tree. 

In this scenario, the idea is to simply setup a new payment method and link it to a desired PMW/DME output like pain.001.001.03. These have long been pre-delivered in standard SAP, in both ECC and S/4. It may be necessary to make minor mapping corrections to meet country- or bank-specific data requirements. Under most circumstances this can be achieved with a functional consultant using DME configuration. Once the payment method is fully configured, it can be linked to your customer and vendor master records or your treasury business partners, for example. 

The new method of generating payment files is via the Advanced Payment Management (SAP APM) module. SAP APM is a module that facilitates the concepts of centralizing payments for your whole group in a so-called payment factory. APM is a module that’s only available in S/4 and is pushed by SAP AG as the new way of implementing payment factories. 

Here it is a matter of linking the new output format to your applicable scenario or ‘payment route’.  

BANK STATEMENTS 

Classical MT940 bank statements are read by SAP using ABAP logic. The code interprets the information that is stored in the file and saves parts of it to internal database tables. The stored internal data is then interpreted a second time to determine how the posting and clearing of open items will take place. 

Processing of CAMT.053 works a bit differently, interpreting the data from the file by a so-called XSLT transformation. This XSLT transformation is a configurable mapping where a CAMT.053 field maps into an internal database table field. SAP has a standard XSLT transformation package that is fairly capable for most use cases. However, certain pieces of useful information in the CAMT.053 may be ignored by SAP. An adjustment to the XSLT transformation can be added to ensure the data is picked up and made available for further interpretation by the system. 

Another fact to be aware of is the difference in Bank Transaction Codes (BTC) between MT940 and CAMT.053. There could be a different level of granularity and the naming convention is different. BTC codes are the main differentiator in SAP to control posting logic.  

SAP Incoming File Mapping Engine (IFME) 

SAP has also put forward a module called Incoming File Mapping Engine (IFME). It serves the purpose as a ‘remapper’ of one output format to another output format. As an example, if your current payment method outputs an MT101, the remapper can take the pieces of information from the MT101 and save it in a pain.001 XML file.  

Although there may be some fringe scenarios for this solution, we do not recommend such an approach as MT101 is generally weaker in terms of data structure and content than XML. Mapping it into some other format will not solve the problems that MT101 has in general. It is much better to directly generate the appropriate format from the internal SAP data directly to ensure maximum richness and structure. However, this should be considered as a last resort or if the solution is temporary. 

Of the many attending corporates and partners were offered the opportunity to hear the latest ins and outs of treasury transformation with S/4HANA.  

Next to the enhancements in S/4HANA Treasury, customers had a clear need to understand what it could means for their Treasury and how they could achieve it. The conference provided an excellent opportunity to exchange ideas with each other and learn from the many case studies presented on treasury transformation.  

Treasury Transformation with SAP S/4HANA 

Alongside Ernst Janssen, Digital Treasury and Banking Manager at dsm-firmenich, Zanders director Deepak Aggarwal presented the value drivers for treasury in an S/4HANA migration. The presentation also included the different target architecture and deployment options, as Ernst talked about the choices made at dsm-firmenich and the rationale behind them in a real-life business case study. Zanders has a long-standing relationship with DSM going back as far as 2001, and has supported them in a number of engagements within SAP treasury. 

In addition, there were similar other presentations on treasury transformation with S/4HANA.  BioNTech presented the case study on centralization of their bank connectivity via APIs for both inbound and outbound bank communication. They are also the first adopters of the new In-House Bank under Advanced Payment Management (APM) solution and integrate the Morgan Money trading platform for money market funds. ABB and PwC talked about their treasury transformation journey on centralization of cash management in a side-car, functionality enhancement through APM, and integration with Central Finance system for balance sheet FX management. Alter Domus and Deloitte presented their treasury transformation via S/4HANA Public Cloud including integrated market data feed and Multi-Bank Connectivity. 

Digital and Streamlined Treasury Management System 

Christian Mnich from SAP laid out the vision of SAP Treasury and Working Capital Management solution as an agile, resilient and sustainable solution delivering end-to-end business processes to all customers in all industries. Christian referred to the market challenges of high inflation and rising interest rates calling for a greater need of bank resiliency and cash forecasting to reduce dependencies on business partners and improve cash utilization while avoiding dipping into debt facilities. The sustainability duties like ESG reporting and carbon offsetting appear to be more relevant than ever to meet global assignments. SAP’s 2023 product strategy was presented with Cloud ERP (public or private) at the core, Business Technology Platform as integration and extension layer, and the surrounding SAP and ecosystem applications, delivering end-to-end integrated processes to the business. 

Trading Platform Integration 

Another focus area was SAP Integration with ICD for Money Market Funds (MMFs) through Trading Platform Integration (TPI) application. MMFs are seen as an attractive alternative to deposits, yielding better returns and diversifying risk through investment in multiple counterparties. Quite often the business is restricted on MMF dealing as a result of system limitations and overhead due to the manual processes. Integration with ICD via TPI offers benefits of single sign on, automated mapping from ICD to SAP Treasury, auto-creation of securities transaction in SAP, email notification and integrated reporting in SAP Treasury. 

Embedded Receivables Finance 

Lastly, SAP integration with Taulia was another focus area to facilitate liquidity management in the companies. Taulia was presented as driving Working Capital Management (WCM) in the companies through its WCM platform and Taulia Multi Funder for efficient share of wallet or discovery of new liquidity. The embedded receivables finance solution in Taulia automates the receivables sales process by automating the status updates of all invoices in Taulia platform and the seller ERP.  

If you are interested in joining SAP Treasury conferences in future, or any of the topics covered, please do reach out to your Zanders’ contacts.