Corporate treasuries have multiple strategic options to consider on how to manage the FX risk positions for which SAP’s standard functionality efficiently supports the activities such as balance sheet hedging and back-to-back economic hedging.

These requirements can be accommodated using applications including “Generate Balance Sheet Exposure Hedge Requests”, and the SAP Hedge Management Cockpit which efficiently joins SAP Exposure Management 2.0, Transaction Management and Hedge Accounting functionality, to create an end to end solution from exposure measurement to hedge relationship activation.

The common trait of these supported strategies is that external hedging is executed using the same currency pair as the underlying exposure currency and target currency. But this is not always the case.

Many multi-national corporations that apply a global centralized approach to FX risk management will choose to prioritize the benefits of natural offsetting of netting exposures over other considerations. One of the techniques frequently used is base currency hedging, where all FX exposures are hedged against one common currency called the “base” currency. This allows the greatest level of position netting where the total risk position is measured and aggregated according to only one dimension– per currency. The organization will then manage these individual currency risk positions as a portfolio and take necessary hedging actions against a single base currency determined by the treasury policy.

For any exposure that is submitted by a subsidiary to the Treasury Center, there are two currency risk components – the exposure currency and the target urrency. The value of the exposure currency is the “known” value, while the target currency value is “unknown”.

The immediate question that rises from this strategy is: How do we accurately record and estimate the target currency value to be hedged if the value is unknown?

To begin the journey, we first need to collect and then record the exposures into a flexible database where we can further process the data later. Experience tells us that the collection of exposures is normally done outside of SAP in a purpose-built tool, third party tool or simply an excel collection template that is interfaced to SAP. However after exposure collection, the SAP Exposure Management 2.0 functionality is capable of handling even the most advanced exposure attribute categorizations and aggregation, to form the database from which we can calculate our positions.

Importantly at this step, we need record the exposure from the perspective of the subsidiary, recording both the exposure currency and value, but also the target currency in the exposure, which at this point is unknown in value.

Internal price estimation
When we consider that for a centralized FX risk management strategy, the financial tool or contract to transfer the risk from the subsidiary to the Treasury Center is normally made through an internal FX forward or some other variation of it. At the point where both the exposure currency and target currency values are fixed according to the deal rate, we can say that it is this same rate we are to use to determine the forecasted target currency value based on the forecasted exposure currency value.

The method to find the internal dealing rate would be agreed between the subsidiary and Treasury Center and in line with the treasury policy. Examples of internal rate pricing strategies may use different sources of data with each presenting different levels of complexity:

• Spot market rates
• Budget or planning rates
• Achieved external hedge rates from recent external trading
• Other quantitative methods

Along with the question of how to calculate and determine the rate, we also need to address where this rate will be stored for easy access when estimating target currency exposure value. For most cases it may be suitable to use SAP Market Data Management tables but may also require a bespoke database table if a more complex derivation of the rate already calculated is required.

Although the complexity of the rate pricing tool may vary anywhere from picking the spot market rate on the day to calculating more complex values per subsidiary agreement, the objective remains the same – how do we calculate the rate, and where do we store this calculated rate for simple access to determine the position.

Position reporting
With exposures submitted and internal rate pricing calculated, we can now estimate our total positions for each participating currency. This entails both accessing the existing exposure data to find the exposure currency values, but also to estimate the target currency values based on the internal price estimation and fixing for each submitted exposure.

Although the hedging strategy may still vastly differ between different organizations on how they eventually cover off this risk and wish to visualize the position reports, the same fundamental inputs apply, and their hedging strategy will mostly define the layout and summarization level of the data that has already been calculated.

These layouts cannot be achieved through standard SAP reports, however by approaching the challenge as shown above, the report is simply an aggregation of the data already calculated into a preferred layout for the business users.

As a final thought, the external FX trades in place can easily be integrated into the report as well, providing more detail about the live hedged and unhedged open positions, even allowing for automatic integration of trade orders into the SAP Trade Platform Integration (TPI) to hedge the open positions, providing a controlled end to end FX risk management solution with Exposure Submission -> Trade Execution straight through processing.

SAP Trade Platform Integration (TPI)
The SAP TPI solution offers significant opportunities, not only for the base currency hedging approach, but also all other hedging strategies that would benefit from a more controlled and dynamic integration to external trade platforms. This topic deserves greater attention and will be discussed in the next edition of the SAP Treasury newsletter.

Conclusion
At first inspection, it may seem that the SAP TRM offering does not provide much assistance to implementing an efficient base currency hedging process. However, when we focus on these individual requirements listed above, we see that a robust solution can be built with highly effective straight through processing, while still benefiting from largely standard SAP capability.

The key is the knowledge of how these building blocks and foundations of the SAP TRM module can be used most effectively with the bespoke developments on internal pricing calculations and position reporting layouts to create a seamless integration between standard and bespoke activities.

This college consisted of a three-part webinar series, in which Zanders explained best practices on important topics in the world of corporate treasury and SAP elaborated on its latest offerings to support the processes with a focus on accelerated and cloud-based deployments.

If you were not able to attend, please find the recorded webinars here. Nevertheless, we now also offer you a short, written summary of what has been discussed.

Forecasting functionalities

The topic of the first webinar was ‘Cash management & cash flow forecasting’. Pieter Sermeus, senior manager at Zanders, explained the preparations needed before you can start daily short-term cash flow forecasting and executing cash management actions. Subsequently, he explained some approaches to prepare a cash flow forecast, whereby he made the distinction in the objective (cash management, hedging or funding) and the term of the forecast (short term, mid-term or long term). Thereafter, SAP’s Christian Mnich and Christian Schmid presented their SAP Cash Management solution. This module in S/4HANA provides support in bank account management, cash positioning and short-term cash flow forecasting, and can be deployed either on premise or in the cloud. Lastly, SAP elaborated on its Analytics Cloud solution, which offers the functionality to report and slice and dice. It also offers functionality in the workflow around collecting cash flow forecasts and the slicing and dicing of the forecasted and actual items.

Payment factory capabilities

The second webinar was on ‘Payment factory optimization’. Ivo Postma, senior manager at Zanders, elaborated on the payment factory process and the relation with various departments within an organization. In addition, different payment factory models (payment forwarding, payments on behalf of and collection on behalf of), connectivity options (SWIFT, cloud provider, host-to-host and e-banking) and cash management structures (zero balance cash pools and virtual accounts) have been discussed. Subsequently, Christian Schmid presented the cloud-based service SAP Multi-Bank Connectivity as well as dedicated payment factory capabilities supported by SAP In-House Cash and SAP Advanced Payment Management.

Process optimization

The topic of the third webinar was ‘Treasury process optimization’. Jonathan Tomlinson, senior manager at Zanders, provided an overview of financial risks managed by Treasury and explained why it is so important and complex to manage FX risk. Subsequently, the Zanders risk management framework was highlighted, including risk identification, risk measurement, policy and execution process issues. As part of the execution process, the whole deal life cycle was discussed. Lastly, Christian Schmid presented SAP’s Treasury and risk management module and the possibilities with its cloud-based Trading platform integration and Hedge management cockpit. Also, SAP Treasury analytics and reporting capabilities for risk management were addressed.

We are very pleased that over 200 professionals registered to the SAP Summer College and that we received positive reactions from the attendees – thank you!

In case you have any question regarding SAP functionalities or other above-mentioned topics, please do not hesitate to contact us.

Intraday Bank Statements offers a cash manager additional insight in estimated closing balances of external bank accounts and therefore provides the information to manage the cash more tightly on the company’s bank accounts.

Compared to intraday bank statement reporting, end-of-day (EOD) bank statement reporting is only available the next calendar day. The information therefore always comes too late to be meaningful for cash management decisions – apart from providing an opening bank balance for the next day.

Business rationale behind IBS reporting

So, why would a Treasury typically start implementing IBS reporting in its cash management processes?

1. Cash visibility: In general, IBS reporting will provide your cash management function an additional tool to improve cash visibility. Achieving cash visibility intrinsically might not be a goal of its own, but by achieving visibility, the cash manager now has information to make certain economically relevant decisions in certain situations.
2. Managing cash: By creating cash visibility, we now have an opportunity to manage cash on our accounts in an intelligent way. In case we estimate a positive closing balance, we could decide to invest this surplus in, for example, a money market fund or overnight deposit to earn some return. In case of an expected deficit, we need to fund the account to ensure no EOD negative position happens. This can be achieved by transferring funds from another bank account (in same currency), swapping funds from another bank account (in different currency), or funding it from, for example, a facility drawdown.
3. Reduced risk of delinquency: As we now implemented a process to increase control over our bank balances, we now have less chance of e.g. rejected payments due to insufficient available funds and therefore less chance of being delinquent on certain obligations to pay.
4. Reduced requirements on overdraft facility: By reducing the chance of having insufficient funds on our account, the overdraft facility requirements can also be reduced.
5. Timely clearing of open items: IBS can also be used to clear off open items throughout the day, as opposed to only rely on clearing from EOD statements. Benefit here is that KPI’s like days sales outstanding (DSO) will improve and that reconciliation effort is spread out more through time.

This article will now only focus on the cash management side; the IBS reconciliation process may be discussed another time. If you like to know more about bank reconciliation using intraday statements, feel free to reach out to us. We have a pre-developed solution that we can implement at your side.

IBS concepts

There are a few design considerations that need to be looked at before attempting to implementing this solution in SAP.

1. Reporting formats: MT942, CAMT.052, BAI2 are formats that can be imported by SAP standard and are also supported by most banks to some degree. There may be some informational or structural benefits that one format has over the other which should be considered in the design.
2. Reporting frequency: It is possible to agree with the bank on reporting frequencies of IBS. Ten times through working hours? Or one time only, half an hour before the payment cut-off time? In most cases, the bank will charge a fee for every statement it sends, so this should be considered in the design.
3. Delta vs cumulative reporting: As it is possible for the bank to report multiple times a day, it is important to understand how the data is reported. There are two methodologies. In case of delta reporting, only new transactions are reported, relative to the previously distributed IBS. Alternatively, there is cumulative reporting, where all booked items are reported on the statement throughout the day. Delta reporting typically means that the data in your SAP system needs to be appended for every new IBS. Cumulative reporting means that every time you process an IBS in SAP, the data needs to be rebuilt completely.
4. Data integration: The intraday data as provided by the bank needs to be integrated with already existing cash-relevant data to compile a proper reporting view of estimated closing balance for the day. This needs to happen in the cash management module of SAP (FF7* reports). The design of the structure of the cash management report should be carefully aligned with the liquidity structure (i.e. ZBA structure).
5. Prevention of duplications: Integrating the intraday data with existing data should be designed with data duplication in mind. It is paramount that the data on the same cash movement is not counted twice from two sources and data duplication should always be prevented while designing the solution. For example, if we are not careful, a payment flow can be included in the report twice, once from the intraday statement when it is debited and once from the payment in transit GL in the SAP administration. This would result in a skewed estimated closing balance.

Ultimately, the goal here is to receive and upload intraday bank statements throughout the day and to load cash movement data into your SAP system. This cash-relevant data needs to be made visible through the cash management reports so that the cash manager can better estimate EOD balances and make intelligent decisions related to funding accounts or investing excess funds.

Setting up Intraday Bank Statement reporting in SAP 

We will now go into detail on how to setup intraday statement reporting and assume that the basic FI-CO settings for e.g. the company code are already in place. We also assume that the EOD bank statement process has already been implemented. To learn how to set this up, please read this article on virtual accounts.

Cash Management 

It is important to understand that intraday statement data is converted into so called ‘Memo Records’ once loaded in SAP. These memo records can be visualized in the cash management reports (FF7AN/FF7BN). We will now explain the necessary settings on the cash management report section to ensure that the intraday data can be made visible in these cash management reports.

_{Define planning levels} 

First, we need to define a planning level; a label that is assigned to all cash movements as reported on the intraday statement. The planning level is used to structure the data in the cash management reports.

The level is a two-digit label, freely definable. We set it to C1.

The sign we need to set to blank as cash movements reported on this level can be both positive and negative.

The source will be ‘BNK’. This ensures that this planning level is reported on both ‘cash position’ and ‘liquidity forecast’ in the FF7AN/FF7BN reports.

The descriptions are freely definable. We define it as ‘INTRADAY’.

_{Define planning types} 

A planning type is a label under which a ‘memo record’ is stored on the SAP database. A planning type is subsequently linked to a ‘planning level’ to ensure the underlying data can be visualized in the cash management reports.

First, we define the planning type label: we set it identical to the planning level; C1 and link it to planning level C1.

We need to define an archiving category. This defines the data retention period of the memo records. If the period is exceeded and the reorganization program is executed; the memo record data will be cleansed.

The auto-expiry option defines whether the memo record will expire automatically and becomes invisible in the cash management report output. This needs to be enabled. The idea here is that the intraday statement data will be superseded by the EOD statement data once this is loaded after midnight next calendar day. To ensure we do not double count identical cash movements from both sources, the intraday data needs to be expired.

Also, a number range and description need to be entered. No specific functional considerations are needed here.

_{Define grouping and maintain headers} 

A ‘grouping’ is a label that is used to structure the cash management report data in a meaningful manner for the user. The grouping can be selected in the cash management reports and is going to dictate how the data is shown to the user.

We will configure a grouping ‘CASHPOS’.

_{Maintain structure} 

Under the grouping we can now maintain the structure of the cash management data. For our report, we are including two components. The first component is the planning level., the second will be the GL account under which we record our bank account balances. This is the GL account we typically maintain in the house bank account data (table T012K, transaction FI13, NWBC).

For the first component we are going to add an entry as follows:

The grouping we set to ‘CASHPOS’.

The type we set to ‘E’ for planning level. Now we can define a planning level that is going to be relevant to our cash management report output.

We set the selection to C1 (our intraday planning level we defined earlier).

This setting will ensure all cash management data as stored under C1 planning level is going to be selected in the report output.

For the second component we are going to add an entry as follows:

The grouping we set to ‘CASHPOS’.

The type we set to ‘G’ for GL Account. Now we can define the bank GL account that is going to be relevant for our cash management report output.

The selection we are going to set to a GL account is saved in our bank account entry in table T012K.

This setting will ensure all cash management data as stored under the GL account and relevant for our bank account will be selected in the report output.

The combination of these two lines is going to ensure that we will only see the C1 data for our one bank account. We can add multiple lines to increase the scope of the reports output.

Importing and processing bank statements 

We should now be in good shape to import our first intraday statements. We could download these statements from our electronic banking platform. Also, we could be in a situation where we already receive them through some automated H2H interface or even through SWIFT. In any case, the statements need to be imported in SAP. This can be achieved through e.g. transaction code FF.5. The most important parameters to understand here are the following:

1. File parameters: Here we define the filename and storage path where our statement is saved. We also need to define what format this file is going to be; MT940, CAMT.053, or one of the many other supported formats
2. Posting parameters: Here we can define whether the line items on the bank statements should be posted to general or sub-ledger. This section is not relevant for intraday statements, as SAP does not support GL postings and reconciliation from intraday statements out of the box.
3. Cash management: This is the most important section, specifically for intraday statement processing. The fields and tick boxes control a few parameters:
   A/CM payment advice: This needs to be enabled to ensure that SAP creates the memo record data from the intraday statements.
   B/Summarization: This tick box controls whether a single memo record will be created for the whole delta balance as reported on the statement or for each reported debit and credit on the statement. If high volumes are expected, summarization can reduce the number of memo records and improve performance a bit. Obviously, it does reduce the data granularity.
   C/Planning type: Here we set the planning type under which the memo records are going to be recorded. In our sample we set this to C1.
   D/ Account balance: This needs to be set if we are loading intraday statements.
4. Algorithms: Here we need to set the range of customer invoice reference number (XBLNR) for the electronic bank statement (EBS) algorithm, to search the payment notes for any such occurrence in a focussed manner. If we would leave these fields empty, the algorithm would not work properly and would not find any open invoice for automatic clearing. This section is not relevant for intraday statements as SAP does not support GL postings and reconciliation from intraday statements out of the box.

Once these parameters are maintained in the import variant, the system will start to load the statements and generate the required postings.

Transaction code: FF.5 

Now we can check if the memo records are updated in table FDES.

Subsequently, we can check the FF7BN report for grouping ‘CASHPOS’ and observe the output.

Therefore, we decided to leverage our cloud-based solution and enable SAP users to determine the arm’s length interest rate with just a few clicks.

The pricing of various treasury transactions, as for all intercompany flows, is subject to transfer pricing regulation. In essence, treasury and tax professionals need to ensure that the pricing is in line with market conditions, i.e. the arm’s length principle. To this end, numerous Zanders clients use the Zanders Inside Transfer Pricing Solution (TPS). Our TPS enables them to set interest rates on intercompany transactions in a compliant and automated way. Since its go-live almost three years ago, clients have priced over 1000 intercompany loans with this self-service solution.

Our TPS has been a stand-alone tool on the Zanders Inside platform, but that is about to change. We have selected SAP as the first treasury management system for online integration. The interface uses APIs between the two systems to pull and push the relevant information. This article will elaborate on how the process flow is designed from an end user perspective.

Automated credit rating assessment

Initially, the necessary static data on the borrowing entities needs to be saved on the Zanders Inside platform. This data is used to determine an entity-specific credit rating, a requirement for a compliant transfer pricing assessment. This can be done via the Zanders Inside template, which gives the user a standard framework to capture the financial statements for all entities. Additionally, the user also saves qualitative rating information. Based on this information, the automated credit rating assessment is run in the background. The borrower credit rating will be used as input to the pricing assessment. This first step is the only manual process in the entire end-to-end flow. In addition, adjustments to the static data only need to occur once per year, i.e. when the new financial statements are published.

Overview

Once the static data is set up, the user enters an intercompany loan in the usual way. In the interest condition, the SAP user will indicate that the interest rate will be determined using the Zanders TPS platform. Using the SAP standard functionality, the user can define if the interest rate has to be updated via the Zanders TPS platform regularly or only initially at deal creation. Once the deal is created, the Zanders TPS cockpit offers an overview of all intercompany loans with outstanding pricing status. From this environment, the user can select the individual deals and raise a pricing request to the Zanders TPS platform. This pricing request will include identification of the lender and borrower, which impacts the rating, and the relevant terms and conditions of the loan, which impact the arm’s length interest rate.

Transferred values

Aside from the rating, the main drivers are the maturity of the loan, the structure of the facility (level of collateral), the currency and the repayment schedule. These values will be transferred into the Zanders Inside TPS. It enables the solution to operate as a calculation engine, i.e. making the necessary calculations in the background.

In the Zanders TPS cockpit, the user is offered the possibility to review the received interest rate and its constituting components. Given the background of the transaction, the user is free to decide which components will be included in the final rate. Additionally, a manual rate adjustment can be added as a separate component, together with an explanatory comment. The manual rate adjustment and its justification is transferred back to the Zanders TPS platform and will be included in the final pricing documentation.

Fully-fledged report

Finally, the output of the transfer pricing solution is twofold. In addition to pulling the interest rate components into SAP, it will automatically create a fully-fledged transfer pricing report. This report will automatically be saved in the solution and includes a reference towards the transaction identifier in SAP. The report contains the methodology as well as all specifics of the calculation and can be used as a reference document later on. This can be used should a tax audit occur, for example.

Determining the interest rate and entering it into the appropriate deal in a TMS system is often a manual and cumbersome process involving different departments. By connecting the Zanders Inside TPS to SAP, the level of straight-through processing (STP) within a treasury department can significantly improve. Additionally, it offers a less error-prone alternative as it removes manual data entry and calculations.

Free Demo

Would you like to learn more on this new initiative or receive a free demo of our solution? Do not hesitate to reach out!

The end of 2021 remains as a key deadline after which the Financial Conduct Authority (FCA) will no longer require banks to submit rates to be used for the calculation of IBOR based reference rates. While regulatory uncertainties and differences between currencies and jurisdictions persist, corporates should have arranged and executed an IBOR transition plan to renegotiate existing contracts, update valuations and financial models, implement new accounting and hedge accounting guidance, and upgrade technology solutions before the end of 2021.

In the Treasury technology space, system providers are already announcing development roadmaps and implementation plans.

In June 2020, SAP announced their development strategy and roadmap for supporting system developments arising from IBOR reform. In addition to developing the additional functionality in S/4HANA, SAP will be down-porting IBOR functionality to ECC EHP8 systems. The first parts of SAP’s release are expected in July 2020 and corporates are encouraged to incorporate SAP’s latest roadmap announcement into their transition plans.

For more information relating to SAP’s roadmap, please see their announcement here or contact Constantine Tyraskis on +44 20 7730 2510.

Are you interested in how these can help your Treasury and how to implement them in SAP? Look no further; in this article we will guide you through the first steps of virtual accounts in SAP.

What are virtual bank accounts?

In its most basic form, a virtual bank account can be described as a bank account number towards which a payment can be initiated, but where ultimately the credit is going to happen on a “real” bank account. It is a service that is mostly associated with a concept called “Collections on behalf”.

“Virtual account” (VA) is a product that is continuously developed by the global cash management banks. Within the product of virtual accounts, there are many variants and sub-services that a bank could support. Some examples:

1. Multitiered virtual accounts: It is possible to create and assign VA’s to i.e. the level of your operating company. On the other hand, to make collections reconciliation more efficient, the bank could offer the possibility to setup a VA that is assigned to one unique trade customer. Any receipt hitting this VA will then be logically and uniquely linkable to that particular trade customer.
2. Virtual sweeping: If line by line crediting into the master account is not desired, a bank could setup a virtual sweep that sweeps the individual credits from the virtual account into the master account in bulk.
3. Separate virtual account bank statement reporting: A separate bank statement could be prepared on the VA level that reports only the debits and credits that hit that VA.
4. Cross border virtual accounts: VA’s could be setup in a different country then where the master account is held.
5. Intercompany position ledger services: Some banks also provide an additional service to record the intercompany positions that arise from the VA movements into the master account movement and reports on it through i.e. an electronic banking platform. Otherwise such IC position mutations need to be managed in the ERP systems of the company on a daily basis.

In the most typical way, a virtual account structure is setup as follows;

1. The real bank account is held by the treasury entity
2. The virtual account is assigned to the operating entity
3. The customers of the operating company will settle trade invoices by making a payment into the virtual account
4. The bank will apply the cash credit from the VA into the master account, for the benefit of the treasury entity
5. The treasury entity and operating company will need to account for this transaction by maintaining an intercompany position.
6. The operating company can clear off its outstanding invoice against the IC position increase.
7. The treasury company can counter the cash increase against the IC position decrease.

Business Rationale behind Virtual Accounts

So why would a treasury typically start implementing virtual accounts in their cash management processes?

Cash centralization: Cash centralization is ultimately the main goal of implementing any liquidity structure and virtual accounts are an excellent in supporting automatic processes to centralize cash to i.e. the treasury entity.

Centralized bank relationship management (and improved negotiating position): By implementing a centrally coordinated liquidity structure, the relationship with the bank can be centrally managed and negotiation position becomes a bit stronger.

Centralized bank connectivity: By implementing a centrally coordinated liquidity structure, bank connectivity can be centralized as well, bringing further reductions in IT costs.

Daylight overdraft facility requirement reduction: Where a zero-balance type of liquidity structure typically brings the funds into the master account after EOD, for any payments made throughout the day being executed over the master account, need to be funded through i.e. a daylight overdraft facility. By employing a virtual account structure on the other hand, the collections will be credited on the master account throughout the day, effectively funding your master account.

Intraday cash balance reporting: in a virtual account setup, as the credits flow in throughout the day on the master account, it becomes feasible to better estimate EOD balances from intraday statement reporting

Reduction of required bank accounts and associated costs: Depending on the bank and country requirements, typically opening a virtual account requires less effort in terms of KYC, contract work and suchlike, as compared to opening up a real account and hanging the account in the liquidity structure through i.e. a zero balancing agreement.

Reduction of vendor confusion: In a more classical Payment factory/Payment on own Behalf (POBO) model where a centralized Treasury entity executes payments on behalf of its operating companies, it is an often heard complaint of the beneficiaries of payments (i.e. trade vendors) that it is unclear that a payment originated from the operating company, causing issues in their reconciliation processes. Executing POBO through a virtual account attempts to remedy this.

This is the first part of a series on how to set up virtual accounts in SAP. Click here to read the second part, on Virtual Accounts Concepts.

What are the main changes influencing treasury’s added value within corporates? Laurens Tijdhof (LT): “Business models are changing. In the decades since the introduction of the internet, ‘digital natives’ – new multinational companies such as Uber […]

Ron Chakravarti, Citi’s global head of treasury advisory, and Zanders partner Laurens Tijdhof discuss some of the key themes.

What are the main changes influencing treasury’s added value within corporates?

Laurens Tijdhof (LT): “Business models are changing. In the decades since the introduction of the internet, ‘digital natives’ – new multinational companies such as Uber and Google – have emerged to disrupt all industry sectors. These companies have less legacy than traditional multinationals. Treasury plays an important role in that digital native environment, for example with payment innovation in ecommerce. Traditional multinationals are typically dealing with a lot of legacy because of mergers and acquisitions throughout their history. For them, the change is more transformational in nature, as they are doing something different than they have done in the past decades or even in the past century. This is one of the elements where treasury can add significant value; to understand from a financial point of view where the business is in the current cycle and to see what things need to be changed, updated or optimized to add value.”

Ron Chakravarti (RC): “Firstly, the pace of change in commerce has picked up, driven by new technologies and new ways of doing business. These are shifting the timing, value, and volume of cash flows and, of course, that impacts treasury. Secondly, while treasury always has to manage regulations and the cash flow impact of changes in global taxation, the pace of change in these have also picked up. Finally, geopolitical uncertainty has created additional considerations at this point in time. Corporate treasurers, therefore, need to ensure their teams are increasingly nimble to deal with all of these issues. The good news is that the availability of new technologies, data and artificial intelligence have the potential to change how treasury works and to create added value.”

At what point are companies ready for new technology?

LT: “Before a company can enter the next stage of treasury maturity, it first needs to get the basics right. This means having a focus on centralization, standardization and automation, typically using traditional technology like a TMS or an ERP system. And if you have these systems in place, be sure you’re using and benefiting them optimally from that environment first. Once you have the basics right, you can go to the next stage of a smart treasury, using the new digital or exponential technologies. Then you can benefit from the good basis and use more of the data in analytical ways, with algorithms or newer technologies like robotic process automation (RPA) or artificial intelligence (AI).”

RC: “I completely agree that getting the basics right, by completing the journey to an efficient treasury comes first. Treasury is on an evolution path of becoming first efficient, then smart, and finally integrated. Getting to efficient means that you must standardize, centralize, and automate. Even among multinational companies, not all have mature, centralized treasury models. Getting to a best in class model is key. In most industries that includes a functionally centralized regionally distributed treasury model, with operational treasury on a common infrastructure and processes. Once you are substantially there, you can work on the next step change, in making the move to a smart treasury. And ultimately to an integrated treasury.”

How should a treasurer deal with the continuous change driven by these exponential technologies?

RC: “Well, an issue is that – as The Future of Treasury whitepaper indicates – only 14 percent of corporates have a digital strategy at the treasury level. Why is this so low? One reason is the availability of the right resources. While treasurers have previously adapted to technology change, this change is all happening a lot faster now – for treasury and the broader business. Ultimately, treasury is all about information. Today, more than ever, the treasury function needs to include people who are technologically savvy. People who are able to comprehend what is changing and how to best deploy technology. That will become increasingly important to create value for the business. Treasury teams recognize that they need to have a digital strategy, but many of them are not fully equipped to define one. They are looking for help from industry leaders with a treasury framework to define their digital treasury strategy. That is one of the reasons for this collaboration between Citi and Zanders; in many cases we recognize that we can better do it together, creating added value for our mutual clients.”

LT: “If you compare the current situation to ten years ago, a treasurer would only buy new technology if there was a real requirement. Today, there’s new technology that many treasurers do not fully understand – in terms of what problems it could potentially solve for the company. What you often see now is that treasurers start with small projects, proofs of concepts, to test some innovative ideas. You can compare it with the iPhone; when Steve Jobs invented it, it took some time before people really understood what to do with it, what value it would add in their life. First you need to see what it is, what it can do for you, whether it can solve a real problem. That’s the exiting stage in which we are now. Some treasurers are trail blazers, others are more followers that first want to learn from others about how it has brought them forward.”

Where can these latest technologies really improve treasury? Are there any issues they cannot solve?

LT: “Treasury is all about information and data. There’s a lot of information available in a treasury environment and you sometimes need new technologies and standardized processes to unlock the value out of these data. Treasury covers a large amount of structured data in all kinds of systems. If you want to translate that data insight into valuable conclusions, then technology is probably the right enabler to help; with data analytics and visualization, for example. But, if you don’t have your data centrally available in a data warehouse or data lake, then that’s the first part you should work on; you first need to have your data centrally available to be able to do something with it. Unfortunately, many large multinational companies are still in that stage, they still have data that’s very fragmented and decentralized. For those companies, you could say that the newest technologies have come too early.”

RC: “What will improve treasury? We should first consider what treasurers are seeking to do. Today, we are seeing an increasing appetite from corporate treasurers for integrated decision support tools going beyond what treasury management systems can provide. To that end, we at Citi are running a number of experiments, collaborating with our clients and fintechs, and enabling our clients’ journey towards smart treasury. This is about moving beyond descriptive analytics to decision support and decision automation, and offering opportunity to realize the full automation of operational treasury. What won’t be solved? Well, we won’t get there in 2020 but we will certainly soon start seeing the foundational steps in this transition to a fully automated operational treasury and that’s what is so exciting.”

Click here to download the whitepaper ‘The Future of Corporate Treasury’.