Tanya Kohen: Tom, on your LinkedIn profile, you mentioned that you value collaborative teams and consistently invest in the people around you. And that's a powerful phrase. With that in mind, do you see invention inside an organization as something primarily people-powered and driven by teamwork, ambition, curiosity, and accountability? Or does it grow more from the technical framework and how a company embeds technology into its operations?

Tom Tarrant: I’ll start by saying it's actually quite a deceptively tough topic to discuss — Buy versus Build. It's actually been quite a challenge preparing for this topic, but I found myself coming down to a few repeating themes. So on this particular question about the drivers for innovation, the more I reflect, the core answer I keep coming back to is the talent. So no surprise, my comments on LinkedIn.

Ultimately, it's the talents and the organizational structure that's key to making it all possible. If you have a core group of inventors and innovators and thinkers, they will be the ones that will ultimately generate the ideas and the potential solutions. And of course, it’s ultimately the people who are actually going to get you there and realize the vision, especially if it's a singular vision.

You need to bring other people on board, get their buy-in on delivery — not just buy-in from leadership, which is often how we think about buy-in. Coming back to your question, of course it's important to combine vision with technical know-how. So what I want to focus on is how we can combine our people and our treasury teams, their invention mindset with that deep IT technical know-how.

Let's get some examples of what this might actually look like. This might be through increased engagement with vendors. A practical example will be pilots. Often pilots involve one of several customers. So a vendor will go out to existing customers or customers in their pipeline and ask them to onboard a pilot as part of a genuine effort of discovery and product development. That's a great way to start combining in-house people with vendors, technical teams, and increase ideas around IT implementation and create energy around the topic. This might also come from different sources of talent in the project itself or within the implementation team.

What I mean by that is, again, a mixing of different groups of people, this case — mixing in-house and external SMEs. And this could be interim or permanent. But something else that's also on the rise is, again, in-house. And that's the representation of innovation at the executive level. This isn't necessarily new, but it's definitely on the rise — seeing Chief Innovation Officers across all sectors and industries, which is an example of organizational structures that are really promoting innovation. And it's a meaningful part of a company's mission.

Bigger company examples would be the Procter&Gamble, the Nikes, and possibly more specific and relevant to treasury — many of the leading retail and investment banks, payment services providers and fintechs all have Chief Innovation in their offices, in their organizational structure. It's part of the DNA of what the company does and it's very in keeping with corporate clients that use those banking and payment and fintech services. So why not — as a corporate who has relationships with the sectors and industries — start adopting some of the same practices. I think history tells us, particularly in tech, that the likes of banking are early adopters of tech and their tech filters into corporates and I think we can start stealing some of their organizational structure as well.

On your specific question of how invention inside the organization is powered, I keep coming back to a couple of key tenets. Number one, looking beyond what is available and tried and tested elsewhere. And possibly my favorite of the two — taking a proactive and conceptual out-of-the-boundaries approach and not just limiting yourself to what has been piloted or proven somewhere else.

I'm sure we'll dive into that a bit later. Just to start wrapping up on this first question. I want to give listeners some food for thought. I want to put the spotlight on the requirement gathering phase, which is something that typically happens at the beginning of the project. I think that requirement gathering is something that can become a more Business As Usual activity — constantly scanning the market for solutions to generate ideas. And that becomes cyclical, it's a very powerful activity to embed in every treasury team. Coming back to organizational structures, I think a lot of us have heard the phrase or seen on a company website that they have a culture of ongoing or continual improvement. It's a common strategy.

But I think some practices or tactics to adopt to achieve this are again: the independent market research, talking to your peer group treasurers — not just for your sector and industry, but organizations of a certain size, more specific to the topic of invention and innovation — talking to other companies who've got a similar taste or ambition for an innovation that you do. It doesn't have to be an obviously comparable company, but look at their attitudes, look at their behaviors.

And another topic that I've stolen, not from a bank this time, but actually from one of your previous guests, maybe even yourself, was the topic of a cross-functional approach. So, talk to your other teams, don't just think about treasury and the immediately adjacent teams, AP and AR. Look a couple of steps up and downstream.

Think of your supply chain finance, teams and applications, customer relationship management apps, KYC, purchase order, fraud and compliance stores, and generate ideas in a collaborative manner as a whole group. And again, just trigger as many ideas as possible.

Tanya Kohen: I think you can build a whole playbook for invention inside an organization just following what you just said, Tom, about all the aspects that are important in an organization, including the org structure and culture. And I think you really unpack the value, what you mean by the value of collaborative teams.

I loved how you mentioned — from a project standpoint — involvement of actually external teams as well and vendor teams. So, the true collaboration happens, first of all, as you just also mentioned, cross-functionally. I very much agree and I'm a strong believer in collaborating internally. Also interesting to hear from you — the perspective of external collaboration. I agree, we are partnering with other organizations and it can be so meaningful if we just always keep in mind that we have the same goal to innovate and invent and to make things better, so that's a very powerful thought.

If we were to move closer to the actual Buy versus Build, and I don't want to put you in a spot here and just say “Okay, Tom, tell me what you think is best.” Just in the nature of this conversation and discussion, I’m really keen to hear your thoughts on that topic.

In treasury, we often face the Build vs Buy decision with systems like TMS, forecasting models, risk dashboards. At first glance, building feels like it's inventive while buying feels like it's a safer bet. How do you see invention showing up in both approaches? If that's the way you see it, of course.

Tom Tarrant: This is where it really does get a bit challenging. I'm trying to come down to a few high level comments that I can really commit to. So this is my attempt. I see building an application or an IT ecosystem of integrated applications more as a task of starting with the need or requirement and customizing for the need. So that's all the build approach versus buy, which tends to invert those two steps to some degree where you have an existing system and you need to configure it to fit a need. So that's a very high level. I think that is a pretty good summary.

But let's get to the question of where invention actually shows up in the start with building. Before getting into the actual treasury activities, I actually want to give some examples of when it comes to invention — is invention in the underlying IT infrastructure, just to give some context. So if we look at infrastructure, and let's think about infrastructure as code — code being instructions to perform activities. So, infrastructure can perform itself in various tasks, including self-healing. Or it can be infrastructure that detects defects and repairs itself, can automate patches for known failure points. Going a bit further, in keeping with infrastructure but thinking about security, let's also think about “zero trust” frameworks where identity management and controls are part of the infrastructure design as opposed to having a zero trust add-on.

Now, when we take the principles from that little spotlight on infrastructure and we come up a level to the application layer, let's think about what this could look like for specific treasury activities. Let's look at a “build” approach that might enable you to set your own design principles and truly execute on those principles. Again, the promise being you start with your requirements and then design. Now, when you set security as the highest priority, suddenly solutions like blockchain and distributed ledger technology become real solutions.

That's an advantage of a “build” approach — setting requirements, design principles, and truly executing them. And so what I'm saying is — if you take a “build” approach, you really open your eyes to all options. Also in this “build” scenario, you might start to home-in on fully exhausting the available controls in an application. Realistically, activating corresponding controls in up- and downstream applications as well. And you'll start to actually see opportunities in the interfaces themselves, not just the applications. Again, with this infrastructure mindset, the interfaces between applications and systems across the company start to become opportunities for controls as well.

I think that there are a lot of opportunities in the “build” approach to really enhance security, those cybersecurity principles, “zero trust”, identity management, things of that nature. If we flip over to invention in the “buying” scenario, I think the emphasis starts to move more towards operational value. So you can be inventive with the available configuration in the application.

For example, building process flow charts, scheduled reminders, reports, automatically triggering downstream processes, simulated and suggested trades, even for compliance and governance. Here I'll throw the spotlight onto user groups. There's a lot of potential to set up bespoke user groups for inputs, for approvals, for monitoring, and that can be monitoring for all the auditors out there — on a level-2 internal audit basis or level-3 legal governance basis. There's lots of options to create different reports that are siloed for different user groups so that they can conduct periodic recons, for example, would be an internal audit use case.

To summarize, I don't think you need to see invention as building everything yourself from scratch. Instead, think about what you want to use any given application for, and what applications you want to use in combination with other applications. For example, purely operational applications versus their potential to add “zero trust” or identity management enhancements or data protection enhancements.

Tanya Kohen: It's so interesting that you mentioned both things that are so critically important. First of all, requirements. Understanding the requirements, which is not trivial at all. And it's even hard sometimes to translate from “this is the pain that I have” into “this is my requirement to the solution”, because — in between — there is what is the solution, right? So this is my pain, what is my solution? And then — here are my requirements for the solution. I think there are prerequisites to even start thinking about Building versus Buying is that you think about what your solution is. Sometimes, very often times, actually, it's not one or the other.

One of the things that I liked to do in my days as a treasurer was just sitting down and mapping out the whole process. I'm very big fan of process management for this reason specifically because a process is not something that uses just one system, never is. It's a combination of different systems and different people managing their processes using different systems. So the user is driving, often times, what's happening in the systems. There is always room for this reason for, first of all, what are your requirements to the system or to the process; do you want to build something, do you want to embed something in an already out-of-the box solution?

And then the other thing is actually collaborating. We're back to collaboration, and I love it, I think this is really important. You can even collaborate with your vendor. You mentioned the tools that users and user groups and all that users do have and actually should use a lot more to help their vendors improve their products.

I think it's a very good approach to thinking about Building and Buying. To maybe dig a little more into this, one argument in favor of building is that the process itself can act as a mirror. It forces a company to reassess a strategy to see where it really stands. Do you think building provides that kind of fresh perspective compared to buying something ready-made?

Tom Tarrant: Just step back and let's set a scene where you're implementing and integrating several bespoke and highly customizable applications. That's your build scenario. That actually gives an insight into the work that goes into developing a ready-to-configure TMS because you're now faced with doing it yourself to some degree. So for example, you're forced to decide on where to house core data. What's going to be your sources of truth for bank account details, as in the company's bank account details.

And our other favorite payment topic in treasury is where are we going to house APs, beneficiary account details? Is that going to be in a TMS or an AP system? That's the topic for another day. But you're having to build and manage file structures as well and mapping rules between multiple interfaces. So, more interfaces than you're probably going to have if you've got an all-in-one TMS. But I will say that building certainly gives you the opportunity to realize a unique vision. So at the outset, it’s worth asking — it's a good test to yourself — if I am thinking of a “build” approach, where is my product going to be substantially different, or — to put it in more blunt terms — where is it actually going to be better than the TMS? If you can't answer that, you're going to struggle to create a business case for yourself or from anyone who's going to sign it off. So, it's a very clear test question. Or at the very least, where do you want it to be better, even if you're unsure whether it's possible?

But having clarity on that point will help you decide whether a “build” approach is worth pursuing at all. You also mentioned strategy in your question. If we take the treasury team strategy and the company financial plan as the mirror that you mentioned or the driver that might drive a need to build rather than buy. And I'll go into some examples of why.

So as a company or, more specifically, the treasury team and its neighbor and friends in FP&A are concerned, as those teams mature as a function, they will want more custom tools. Now, as I hinted earlier, I tend to start with “buy is for ops and build is for strategy”. In other words, a bought solution might not support the metrics and assumptions of the company financial plan, which would drive a need for a custom built solution. So, drilling down a bit further, the “buy” approach can actually hit limits. Most off-the-shelf treasury management systems are built around fairly standardized daily activities, albeit essential daily activities, cash positioning, bank connectivity, payment execution, basic risk management, general generation bank recs, all core treasury activities. But a company's financial plan — again, keep in the context that treasury and FP&A will often work very closely — can contain elements that don't map neatly or fully to a TMS.

A few areas where this happens is actually even in forecasting inputs. We love to talk about the power of TMSs in forecasting, but are the forecasts that are limited to treasury use and not as useful in FP&A? So a constraint could be that many TMS cash forecast modules expect simple direct inputs from AP and AR and payroll and even treasury's debt portfolio and loan servicing commitments versus a financial plan, which often includes non-standard drivers, customer usage patterns, commodity exposures, M&A scenarios. Now, these are complex and non-standard forecast inputs, which are probably going to be better modeled in a custom tool or FP&A system.

I think it's a particularly important example, again, as corporate finance teams often include Treasury and FP&A. Other examples might be capital structure scenarios, where financial plans model future debt issuance, share repurchases, often modeling ratings impacts. And a quick list of other examples that all these complex examples will be FX and IO effects and IR risk simulations, long-term strategic initiatives, have all of your JVs, research and development, M&A and divestiture, tax and inter-company planning and transfer pricing. My point here is there are a long list of complex scenarios that are probably not going to be supported in your TMS. So straight away you've got a long list of reasons why you might want to explore a “build” approach if you're taking a collaborative approach not just working as treasury, and this is just the list thinking about all the possibilities working with one other team namely FP&A.

Tanya Kohen: I wrote it down — “buy is for ops, build is for strategy”. You can use it as a framework, and you really gave much more details to it. There is a lot to think about, for each company is unique.

I love the example with forecasting. Each company is unique with how it forecasts, for example. There's never a cookie cutter solution that's just out of the box, never really works if we were to really drive change and improvement. It can do the job day-to-day maybe, but as teams get more sophisticated with their analysis, it's inevitable that you need something in addition, including skills, hardcore finance skills teams have to have, but also proper tools can just enhance it.

On this note, let me ask you about AI. I know it's a huge topic. In the context of what we've been discussing today. So with AI and low-code code tools that are available today, companies can buy a foundation. Again, this is where I'm coming from and how I like to think about this. I'd be curious to hear your opinion. Let's say, a treasury management system can be a foundation, but then, it is possible to build custom layers on top of that, like AI engine for forecasting, or anomaly detection. So do you see this hybrid approach as the new model?

Tom Tarrant: You and I both know it's already happening. So yes, it's the quick answer. Will this be a lasting change and add real value? It's the additional question I'll challenge myself with. But I still think the answer is yes. Again, let's go through a few specific and frankly common use cases for intelligent applications over and above machine learning solutions. I think that's the battle here and where we need to look for the differentiators between the machine learning and between the quote-unquote intelligent solutions. One of the most discussed treasury use cases, said earlier, no prices for guessing, but it's an important one is machine learning driven forecasting, which typically leverages those inputs we just talked about: the common TMS data AP/AR inputs, maybe in some cases — some inventory and PO inputs as well. But the TMS forecast generation tools have typically been linear, or relationship-based between a couple of data points. Whereas an AI overlay can detect the hidden or non-linear or contextual subtle patterns. So straight away, that is your differentiator between AI and ML. And if there's a more advanced solution available, you really have to ask yourself — why you would go for any other solution.

Again, it's a hard and clear question to ask yourself if you're building a value case or a business case. This ability for more intelligent solutions to look for non-linear or more subtle patterns in broader contextual data is the key differentiator for me. And this has potential value add for, I'll limit myself to a shorter list this time: Intelligent Reconciliation's not having to build your rules and have a system scanning to match forecasts and actuals. For payment fraud, anomaly detection, going into that bit in a bit more detail later on, I think that's quite an exceptional topic, but also FX and IR analytics. Your TMS is going to be largely limited to value at risk as opposed to the stress test that, again, most FP&A teams are going to require, which we need to factor in different macro scenarios as well.

Tanya Kohen: Tom, if you were to give one piece of advice to leaders weighing Build versus Buy today, what would it be?

Tom Tarrant: This is actually probably my favourite topic because it is a term that's out there and that term is operational resilience. For me, it's incredibly valuable, incredibly important. I'm saying the phrase already exists, but where does that phrase belong? I really think that long-term operational resilience is the value add that needs to be at the core of the business case technology. I have to give credit to some degree to one of your previous guests, Tracy Knight, episode two. She talks about the difference between a value case based on fixing problems versus adding future value. And that really resonated with me.

The reality is that every organization or many, I should say, will have some problem areas where they want to patch, fix, replace, retire, whatever it might be. But having a long-term view to build in operational resilience, ability to scale, ability to protect the organization operationally and on a controls basis is such an important value case.

What does that look like? Again, I know you asked me for a short answer. I just want to give a couple of specific examples of what that could look like in practice.

Number one — allow for a long ranging series of smaller, minimum viable projects. Really focus on project success. It can sound obvious, but plan for that early on. Plan for what you can essentially strip out of scope, so that your core scope is protected, but always aim for more than your absolute minimum — so that stripping out is a valid approach. Make sure each minimum viable project is actually completed and embedded before you move on. That's the whole point of a minimum viable project is that you're increasing the odds of success. So absolutely don't move on until it's completed and embedded, built for value and resilience incrementally. Come back to this idea of a series of minimum viable projects. Easy to advise, but these are such important core staple approaches to take, really important.

Tanya Kohen: It is so important that we not only discussed the advice itself, what needs to be done, but also you touched with examples and frameworks of the execution piece itself. So not only you mentioned what needs to be done, but how, what is the approach to actually executing this, these things. So I think it's very important for our listeners to also put some thought into how to apply this uniquely to their organizations and their processes. Thank you for that. Shall we move to our rapid fire questions and final three questions for you?

What does an invention mindset mean to you?

Tom Tarrant: Be bold. Be bold enough to be the first. You know, you've really got to set aside what can be done or, more specifically, what you have previously done or what you've seen other people do. We all know that it is a valid approach to what's been done before and what's defensible when building a business case. But do think about how you want to spend your time. And again, a test question to ask yourself if you're writing a paper or talking to colleagues: ask yourself, what would you do if this was your own money? Come back to this most basic question. You've got your own startup, your own private limited company. It's the genuine question. And if you can arrive at a clear answer to that question, then you're spending your time well, building a business case. It also means again, this “being bold” approach, valuing your own point of view. If you've done research and you're seeing signs that there's an alternative approach supported by products, solutions and services that are available in the market, perhaps you should be exploring those. But be prepared on a practical basis if you're taking a sidestep and taking a new approach — be prepared to advocate your proposal against whatever the expected traditional approach might be. Be prepared to argue against that approach.

I do remember actually one FTSE-100 treasurer saying to me: “I'm not afraid of complex global landscapes and integrations”. I think it was said sincerely and I think that's a really nice example of a couple of things we touched on today. I think it's the right mindset. It's this inventive, ambitious, innovative mindset, but also coming from leadership. Someone who's going to support people who come forward with proposals that match that mindset. So again, this people element, you knew I was going to come back to it and I just did.

Tanya Kohen: Right. What do you think is missing in today's tech stack for finance and ops, if anything?

Tom Tarrant: I think we're too focused on tech as an operational layer rather than a strategic layer. Going even further than that, I think there are opportunities and, frankly, requirements to look at tech for regulatory compliance that could be anti-frauds, economic crime, even KYC. I think it's an area that's gaining momentum. But I think there's quite a clear divide between the operational and the strategic and compliance all into one bucket, I think there's possibly a lack of take up on tech solutions in that area.

Tanya Kohen: Understood. If you could improve one thing in a business, not necessarily tech related, what would it be?

Tom Tarrant: It's promoting and recruiting talent in the field of innovation itself. We talked about the Chief Innovations Officer. That's great, that’s the exec level. Arguably, it’s the wrong way around needing operational teams with similar complementary roles.

I'm sure it's happening out there. It's part of some people's roles. I'm sure there is a mass of people who wouldn't want to be doing work that's 80, 90 or even 100% of their role is innovation and invention. But it's the time to do it. It's something I'd like to think I would implement if I was running my own treasury team.