Published: May 10, 2022
Treasury is an increasingly technology-enhanced function, and some treasurers have taken their involvement to the next level, building their own solutions. In the company of those who have travelled this path, we explore the build-buy-partner conundrum.
Treasury technology is becoming increasingly useful and, with the advent of cloud, arguably cheaper to acquire and maintain. But that doesn’t stop some treasurers engaging in projects to either self-build or develop solutions that better cover their needs.
The driver for involvement at this level may be frustration that the perfect tool does not exist. It may also be a way of satisfying a technological curiosity, or even a notion that a new business is in the making. The motivation for Peter Zmidzinski, Founder of SwissMetrics, a digital risk management platform, spans all of these.
Peter Zmidzinski
Founder, SwissMetrics
Today, Zmidzinski is a fintech entrepreneur. But he started the project to build his platform while still a tech-curious treasurer, having realised a need for a single-platform solution to help him manage counterparty onboarding, compliance and credit risk monitoring. Naturally, he is very much in favour of treasurers exploring the possibilities of self-build.
Of course, for a treasury professional to build their own solution, several abilities and interests must align. For Zmidzinski, who has a number of years’ senior international treasury practice under his belt, most recently as Head of Treasury for aviation services firm Swissport International, the treasury component was well-rehearsed. The technical knowledge to build what he wanted was something he had to develop on the way, guided by his enduring interest in technology.
“I’m a risk manager and very conservative by nature, so I’d been working on the SwissMetrics platform for a few years already in my previous roles,” he explains. At Swissport (and previous firm, Nyrstar) he’d had plenty of dealings with smaller counterparties around the world, for which there was very little accurate or up-to-date credit risk information available through the usual channels, such as Experian and Dun & Bradstreet.
Convinced he could do a better job of providing useful and timely counterparty risk assessment data, Zmidzinski set about developing a prototype platform. By offering access to colleagues in various functions, he gained sufficient feedback confirming that his idea had real value. When the Covid-19 pandemic first hit in 2020, it signalled crunch time. “I thought, ‘Do I want to continue doing the same thing, or do I push forward with my growth and learning, developing the entrepreneurial side of me?’ – and so we launched.”
With his treasury experience derived from medium-size companies, the technological resources and expertise open to him were always relatively limited. To help define his quest, he has always seen certain elements of the function as being open to technological refinement where others are not. “When I consider the tech-landscape and the possibility of self-build, I’ve always split treasury into its component parts,” he says.
The first is data analytics, bringing together multiple inputs from ERPs, market data and other operational systems to evaluate, for example, FX exposures, liquidity or cash forecasting. “Ideally, these data points should be brought into a singular treasury system, such as a TMS,” says Zmidzinski. “This is where the discussion around in-house versus outsourced developmental work for analytical tools can take place, with treasury able to create its own data warehouse and customise existing tools such as Microsoft Power BI towards its own needs.”
The next component is transactional treasury, with multiple activities being recorded into a core system (usually an ERP or TMS). These systems are typically off-the-shelf vendor offerings. While there may be an element of in-house configuration possible, the complex role of the core system means it will be very rare for a business to build its own (although a handful of sophisticated treasuries have). “The data recording part alone is just too complex,” comments Zmidzinski. “I’ve seen instances where Access databases were being used in treasury for this purpose, but as treasury has expanded its role, so these have proven deeply error-prone, with compliance and security issues creating major concerns. A configurable vendor solution is preferable.”
With a large pool of recorded transactional data to manage, the final component of the treasury process map for Zmidzinski is reporting. “This is where I see build-your-own or customisation work most likely taking place,” he says. “Treasury can then interface its own reporting tools with internal systems such as the data warehouse and the ERP.”
Perhaps the greatest challenge for any self-build project is securing the internal resources, says Zmidzinski. Only the largest companies will have anything approaching a dedicated treasury IT function. For most with general IT resources, treasury may be able to secure assistance with the routing of data into tools such as Power BI. In the context of such a project, treasury’s role becomes akin to that of project manager. “Even for this it will be best served if it can co-ordinate its own data needs and translate all of its requirements into meaningful IT terminology. For this reason it’s very helpful to have a solid understanding of the technologies being used,” he says.
In particular, Zmidzinski believes that it is beneficial for treasurers to understand how data is structured, and to “think like a data scientist” when it comes to inputting and extracting data from various systems. “Some years ago, I embarked upon an SQL course, getting to grips with this programming language so that I could better understand relational databases and work on the data in them,” he recalls. “I found that it helps to communicate more effectively with IT. If you understand how data is structured, and you can understand what is possible, you’re more likely to achieve what you want, rather than what IT thinks you want.”
SQL remains the most common language in use for data work but Zmidzinski adds that it’s also helpful to study a general-purpose object-oriented programming language such as Python (or perhaps the slightly more complex Java or JavaScript). “Understanding the building blocks of a system can take you so much further.”
While an understanding of data analytics is often incorporated into undergraduate-level finance studies, a broad look at technology is not necessarily part of formal professional treasury training. For Zmidzinski, it should be. “In the fundamental treasury courses, a general technology module that at least explores data structuring and integration would be advantageous,” he suggests.
Zmidzinski admits to having had no direct exposure to the frameworks and processes often adopted by consultants in the treasury technology space. Instead, says, “it was more a case of rolling up the sleeves and getting on with it”. Although he refers to his own informal approach as “agile”, with rapid reviews and response to feedback possible, he says “it would have been more efficient if I’d learnt about project management and development frameworks such as Six Sigma earlier in my career”.
It’s a lesson worth learning, but Zmidzinski feels the real key to project success is finding people with experience in something similar and discussing their processes and findings with them. “Particularly when you start on the implementation phase, it’s easy to follow a certain route for some distance before realising it is not the right way,” he says. “That’s where tapping into experience really makes a difference.”
It highlights the value of the treasury community – found in abundance within the national treasury associations – as an invaluable resource and sounding board. However, Zmidzinski argues that it may be more prudent to obtain the services of an experienced external implementation partner. A third-party provider will often be able to do the job quicker. It may seem more expensive initially, but in the long run it could be a cost saving. “If you do take the third-party route, it’s vital to secure knowledge transfer back to the organisation, especially around system maintenance, otherwise you will be forever beholden to them.”
“It is to be expected that other ad hoc priorities will emerge within the wider business, and that as a result project timelines may be stretched,” cautions Zmidzinski. “It’s why being on top of those, lining up the resources and ensuring they can be available throughout, is the most challenging part.”
Whether securing internal resources is likely to prove challenging or not, he says his first objective is to bring all stakeholders on board as early as possible. “This way you can inform them upfront of the project’s goals, and what may be required of them.” Of course, bringing associated functions into the project helps share the workload. But doing so not only ensures early feedback and reaction to its up and downstream impacts, but it will also facilitate the sharing of knowledge for future maintenance work.
Within treasury, junior personnel should consider becoming involved where possible in any technology project, says Zmidzinski. “It helps build upon their knowledge and experience of systems and processes, ready for the next project, which in turn can aid their career development,” he explains.
Having found an unmet need for a niche treasury solution, built and developed it, and subsequently taken his solution to market, Zmidzinski amply demonstrates that the self-build approach is feasible. However, not every treasurer will want to take their idea this far. “It’s a big leap to go to market and it has been a steep learning curve to get to this stage,” he says. With that in mind, he reiterates his earlier view that few, if any, companies now have the appetite to develop a core system, but the creation and integration of niche reporting and analytical tools by treasury is still feasible.
Some individuals have a passion for learning, even when at a technical level the curve can be particularly steep. This is the case for Patrick Kunz, Treasury, Finance & Risk Consultant and Interim Treasurer, Pecunia Treasury & Finance.
Patrick Kunz
Treasury, Finance & Risk Consultant and Interim Treasurer, Pecunia Treasury & Finance
Indeed, in his role as an interim treasurer and professional advisor, Kunz has occasionally found himself having to deep-dive into the client’s IT architecture far more than expected. Rapidly learning the nuances of a particular system, he says, is often a necessity just to be able to converse on an equal footing with the client’s banks and vendors. Surely then he encourages self-build?
“Five or ten years ago, there were more in-house projects in treasury than today,” he muses. “But as core systems have become increasingly integrated, traditional TMS functionality is being augmented by a host of new tools. By building these one-stop-shops, vendors are making it more appealing to treasurers to deploy a core system, so often I find there’s little need to self-build.”
This assertion sets out his stall clearly, however, Kunz notes that some companies still feel they have special needs, not necessarily solely around treasury, but certainly in the wider flow of their financial data. As such, their needs are not being met ‘off-the-shelf’. This has seen core systems, particularly SAP, being subject to multiple customisation projects.
But today, SAP better understands the value of meeting client needs by enhancing its own platform. It often does so through third-party tech firms such as Serrala and Nomentia which build and implement SAP-approved treasury add-ons. With most bases now covered, even for the special cases, Kunz remains predominantly in the ‘buy not build’ camp.
For those treasuries that still insist on tailoring or building a solution, and choose to do so in-house, Kunz warns that a project of any significance can rarely be achieved alone. Managing data can be especially challenging. “Some treasury data comes externally, from banks or market data providers, and these sources can usually be easily connected. But internal data – payments systems and files, vendor and basic master data, for example – may come from multiple sources, requiring multiple connections”. For this reason, he believes treasury will always need help with finding, cleaning and aggregating information from multiple sources.
The data gathering itself is not necessarily the greatest issue, he continues. This comes when corporate data from multiple systems is not of the same format and quality. “I’ve undertaken payment hub projects where one ERP contained significantly better data quality than another. When integrating these into a single source, resolving issues with missing or incorrect data required a major database mapping exercise, which even for experts can take a long time.”
It’s why, for every project, and especially where automation is the aim, Kunz says planning is essential. For a database project, this should at least define the extent and nature of the information needed, with every data source being precisely mapped. Only then can work begin to identify how best to extract, pool and treat that data.
Kunz also cautions treasurers against being overly captivated by the promises of AI or ML if the fundamentals are not first taken care of. These tools will not cure existing problems. But by getting the fundamentals in order, he says some 70% to 80% of the required data may now be readily available. “Then you can start bringing in additional sources and tools,” he says. But even at this stage it is vital to set realistic objectives. “Don’t set out to achieve 100% availability, because the effort and cost needed to reach the final few percent may be neither cost-effective nor necessary.”
Of course, AI and ML can add a lot of value, but these systems need to be constantly revisited to ensure they are guiding treasury along the most productive path. This means tuning every input assumption around trading and environmental conditions, or current business model, for example. Indeed, recent extreme market volatility would not have been incorporated into the output of a system using uncorrected historical performance data, with treasury KPIs set for forecasting accuracy being missed.
Even seemingly simple matters can create problems for the inexperienced treasury technologist. Cashflow forecasting in particular will have many data sources, meaning complications often occur with data availability and formatting, warns Kunz. When this occurs, resolving differences between sources can delay a project and add to its cost.
“If you want to automate data capture, for example, you have to think about the minor details,” he advises. “I had a client where the currency code field was only added if it was a non-functional currency. In the Netherlands, if it was GBP, USD or CHF, it was entered, but if it was EUR, it was left blank. For the subsidiary in the UK, it did not fill the GBP currency code field, but did for EUR, US and CHF, and so it continued.”
In this case, the client had to decide how to map these fields. It couldn’t simply say ‘if empty, it’s EUR’, because that might not be the functional currency of the entity. While an easy, but labour-intensive work-around manually, for process automation to be successful at all, additional programming was necessary. “For a treasurer seeking to create a tool to capture organisational data, where different data sources and different settings are used from country-to country, entity-to-entity and system-to-system, failing to respond to this apparently simple step could present a serious roadblock.”
Given the potential for complexity within the corporate technology landscape, even around elements of minor detail, treasurers at the very least must grasp database management techniques before considering an inhouse project, says Kunz.
However, he also warns that it’s unwise to rely wholly on system vendors to come to the rescue: “They will say they can do everything, but the devil is always in the detail.” What’s more, he believes that it’s wise not to rely too heavily on internal IT. “Not only can this sometimes prove to be a rare resource to secure, but IT may not always understand the information with which they are working.”
Realising this at an early stage of his treasury career, Kunz immersed himself in the technical detail of treasury, learning for example how to read SWIFT MT940 and MT101 messages. “On first view they look like a bewildering mass of numbers and letters,” he comments. “But once you can identity each field, it’s easier, for instance, to see why a message fails – and it could be something as minor as a misplaced full stop or comma.” In such cases, where treasury will usually rely on IT, an understanding of message protocols means the treasurer can correct the error and not have to wait for IT resources, or even have to explain what each component of a message means from a treasury perspective.
With his natural inquisitiveness and ability to understand the technical environment, Kunz says he could almost carry out an implementation himself. “I can fully understand which files need to be exchanged on which databases, and how SFTPs [Secure File Transfer Protocols] and the links between them work. That helps me a lot in understanding the flows and information exchanges between systems, but building databases is my limit.”
Having the wherewithal to understand, at a more detailed level, the nature of treasury technology is clearly advantageous in its day-to-day running. This is especially true when handling vendors or explaining to internal IT what is required of any fixes or enhancements. But it is a big step up to build a system in-house, and Kunz remains unconvinced that this is the best way forward for most treasury teams.
“There are many vendors in the market, and in the current landscape several have grown and developed their offerings to meet most treasury needs,” he says. “If you have explored all that are relevant and have concluded that none offer precisely what you require, even if customisation and co-creation is suggested to fill the gap, then an inhouse build may be the way to go,” he comments. “For me, self-build would be a ‘no’.”
Before you start
Progressing ideas
Friendly advice
As a formally trained software and systems developer, Anita Bubna, Senior Director Treasury, Flex Group, is perhaps more qualified than most to get under the hood of modern treasury systems. With this in mind she was able to identify a use case for procure-to-pay and order-to-cash. This concept was further developed by Flex’s treasurer who then entered into the strategic partnership that formed recently between Flex and its collaborators, a trade finance and working capital asset platform vendor, and a blockchain-based digital asset servicing platform provider.
The shared venture will enable Flex’s customers, suppliers and partners to connect using APIs or standard connectivity via the same platform. What’s more, once the data volumes and quality are at a sufficiently high level, the project will see advanced tools such as ML being introduced to enhance the experience. “We have all the building blocks ready so this part should be relatively straightforward – and frankly it’s the fun part of the whole exercise,” Bubna declares.
Anita Bubna
Senior Director Treasury, Flex Group
The kind of knowledge and skill required to feel comfortable taking on an in-house build project are many and varied. “For a business person on the treasury side, they mostly need to have an in-depth understanding of their process, and an understanding of how systems ‘think’,” she says. This means understanding some programming concepts and how databases work.
“Knowledge of Microsoft’s Visual Basic for Applications (VBA) programming can allow the users to do some light programming on their own, to automate several manual tasks in treasury without waiting for an IT team,” notes Bubna. “Then, a grasp of how to use data visualisation tools, such as Tableau and Power BI, can also be very handy, helping the treasury professional to easily prepare graphs and charts for presentations.”
For most treasury operations though, Bubna considers that the basics are more important than the detailed knowledge of, for example, data science. “But I also believe that an understanding of some programming and database concepts is key, as even if the treasury professionals don’t want to program, they still need to understand these concepts to work with IT, other treasurers and treasury systems.”
For those treasurers who are eager to begin tackling in-house projects, setting up custom training for their team is worthwhile, says Bubna. Any training programme should of course be based on the tools that the company uses, and the role that the particular individual plays.
For these training sessions to be truly effective, the training should include practical projects wherever possible, as this will ensure the team can make eventual use of these tools, notes Bubna. Treasury should also consider partnering with the learning and development team of the company, if it has one, to identify any skills gaps.
“This can aid in finding the most suitable training partners, developing training roadmaps, and providing a means of assessing the effectiveness of the training so that course adjustments can be made,” she says. “It may also be beneficial in the longer-term to establish formal focused training for new hires and for those that need or want to upgrade their skills as they rotate through different roles.”
The nature of any niche system project that is to be tackled in-house is that there will be plenty of challenges on the journey. Bubna speaks from experience, advising a state of preparedness before taking the leap.
One of the first buffers treasury may come against is securing resources. “There will be a huge list of projects in any IT pipeline, and it may take several months before treasury’s project can make it to the top of the list,” she warns. “Taking the time to develop a strong business case, and showing the commercial benefits of the project, can be helpful in getting resources allocated.”
The skillset of the internal team may also be found wanting in terms of its grasp of the latest technologies. “Where it is available, combining an off-the-shelf third party application with an internal development effort is a great way to make the most of both worlds,” explains Bubna.
As an example, she says where an external application may not offer user- or executive-friendly reporting, or when data from an external system needs to be combined with other internal systems, “complementing an external application with some work from internal resources can be a great solution”.
It may also be that the technological skillset of the treasury team itself is not as well-honed as it could be. A treasury professional who has an understanding of IT systems and processes will certainly be needed for automation work to be successful, explains Bubna.
Also, significant time will be needed from the treasury professional to achieve results. “Expecting someone to take care of the day-to-day treasury tasks while simultaneously working on an automation project can be demanding, and will likely cause delays,” she notes. “If possible, it may be advantageous to transfer the day-to-day responsibilities to someone else in the group for the duration, or if that is not possible, hire an external consultant or interim to manage the project.”
One final challenge that Bubna cites is one that is often neglected or left to chance: project attrition. “The individual managing the project can leave. To avoid the impact of such an event, it is vital to document the project specifications, approvals, and any exchanges of information. It’s also advisable to engage a second person to be part of the process, who can step in if and when the key person moves on.”
The best way to ensure that treasury is making the right choice when embarking on an in-house project is to ask probing questions. “If your honest answer to many of these questions is ‘no’, then it is better to outsource rather than build,” says Bubna.
It’s true that technological progress, especially with APIs, is simplifying communication between an ever-expanding array of niche applications offered by the fintech community. As such, the argument for ‘buy not build’ is increasingly compelling, especially as treasuries are driven by volatile times to focus on their core functions.
However, as Zmidzinski noted above, the knowledge and experience gained from “rolling up the sleeves and getting on with it” will still appeal to the technologically-minded treasurer in need of something unique. What’s more, the knowledge accumulated puts the treasurer on a more even footing with IT for future projects.
Since the first APIs started appearing in the bank-to-treasury space a few years ago, driven in part by the open banking revolution, there has been much talk of their transformational power. We consider the reality behind the claim, exploring the possibilities and the limitations. The promise of system flexibility, agility, and scalability is a potent […]
