How do you design and implement a treasury governance framework that supports transformation?

Exploring ways to craft and execute a robust treasury governance framework that seamlessly aligns with organizational transformation initiatives is quite intriguing. One key aspect lies in identifying the intricate balance between risk management, compliance, and strategic objectives. Leveraging a collaborative approach across departments, we can delve into establishing clear policies, defining decision-making protocols, and implementing robust monitoring mechanisms. It's about fostering a culture of transparency, agility, and accountability within the treasury function, thereby empowering the organization to navigate transformational journeys with resilience and efficacy.

I would Start by identifying the areas where your treasury function is performing well. For example, you might have an accurate cash forecasting process or a robust system for managing FX risk. Next, I'd identify the areas where your treasury function is falling short. This may include a lack of visibility into cash positions, inefficient bank relationship management processes, or inadequate cash movement controls. Both strengths and weaknesses should be assessed using blind surveys, 360 assessments and external benchmarking.

Engage with the organisation to determine what type of Treasury they want or proffer options. The options will be based on the type of functions they envisage, their current market environment and the firm's capital structure. This initial assessment would be a foundation for determining the final state and identifying the gaps.

From experience, implementing a treasury governance framework that supports transformation is important to achieve the strategic goals. We start by defining clear objectives and goals to guide the framework's development. Then, set robust policies, procedures, and controls to ensure compliance and mitigate risks. Next is to incorporate flexibility and adaptability to account for any changes in technology, regulations, and market conditions. Most importantly, is to facilitate collaboration and communication across departments for proper synergy.

My starting point would be to source a list of typical treasury capabilities (e.g. cash and liquidity management, FX hedging, IR hedging, etc.) and identify which one are relevant for your business independently of what is currently in place. This is to ensure gaps are identified as well as understanding what good looks like for your firm.

The target state assessment should involve: - The work carried out from strengths and weaknesses. - Identifying the new opportunities: i.e considering potential areas for improvement, including optimizing cash balances, improving forecasting accuracy, or reducing the cost of funding. - Stating and mitigating the genuine threats to a successful outcome including a rapidly changing macro environment, internal resistance to change and cost or budget pressures.

I agree with this, but there is an intermediary step in my opinion: define both vision and mission statement of the treasury function in context of the wider business objective, strategy and activity. I have seen many organisations make the mistake of jumping to solution / target state without understanding where their firm needed such function to go. Treasury does not operate in vacuum and it is there to enable the broader organisation both at strategic and operational level.

Start small! Definitely, an unpopular way to go, but proven time and time again to work. The priority delivery one should focus on where the bucket is leaking most. This could be in terms of actual costs or opportunity costs of regulatory pressure costs. Then, map priority two. Then three A matrix of risk importance from 1-5 should be developed so the rankings can be When the first ten riskiest/costliest areas are mapped, this then forms the initial roadmap which can then be compared to resource dependencies.

I would reformulate this in terms of breaking down the vision and target state into smaller chunks (ie. milestones) that are sufficiently close from a timeframe perspective to ensure both leadership and operational teams can see tangible change quickly.

Yes but this is tricky. A policy can help you establish the rules of the game. But that also means that everything outside of these "rules" is potentially not allowed/possible. I like to write short and concise policies. not to use within the treasury department as we know the rules of the game. The policy should mainly be used for other internal stakeholders like finance, fp&a, tax, procurement etc so they also understand the rules and guidelines of treasury. Treasury is never standalone so adherence of those deparments is crucial to a well functioning treasury information flow.

Procedures are notoriously difficult to keep up to date or maintain relevance. The best model I've seen treats policies, procedures and SOPs as a product. The product model maps out the regulatory and industry standards in a wiki style. Then on top of this are layered the company's specific policy features. This is updated in real time, but subject to submission review on a weekly basis.

There should be some frameworks and associated procedures, not procedures only. A framework translate the policy requirements into an operational tool and the procedure define how the tool will be operated ...

The Treasury team would have been the key drivers for the development and delivery of the product. As such, they will help drive the roll-out and reduce internal departmental friction.

I'd disagree with most practitioners on this point. I think 30% of the budget/project resources should be ring-fenced to deal with monitoring for a 9-12 month period. This is where the leaning happens and true delivery benefit is achieved.

The monitoring must include horizon scanning. As new businesses develop and new regulations are issued, the list of capabilities required to run the Treasury function will also evolve.

A Product lens vs a Project lens is the key flip required to deliver successful projects. This puts the users, management and project team in an iterative mindset as opposed to a 'one and done' approach which rarely works.