Treasury Control in a Decentralized Company: When the Textbook Doesn't Work

Matthias: Let's say cash balances are just entered manually — it's a huge strain on the local teams.

Philip: Why is visibility key for you?

Matthias: Because then you can make the proper decisions. If you don't have complete data, then your analysis is largely made on assumptions. If you have daily visibility, you can see the flows. You understand the company much better.

Philip: Matthias Depoorter is the group treasury manager at Euroports and former international treasurer at Alliance Laundry Systems LLC. He specializes in treasury management, risk mitigation, and global financial operations, helping organizations optimize liquidity, working capital, and cash visibility across international operations.

Matthias: The MT101 cost, depending on the bank, can be very expensive. We had one bank that charged €53 per payment.

Philip: Per payment.

Matthias: And then the local entities were like, "Wait, we're not going to pay that. If we do that times 220 days — Jesus." And then I came up with solutions.

Philip: So welcome to this latest episode of Treasury Leaders. Today's guest is Matthias Depoorter, group treasury manager at Euroports, and Euroports is one of the major port and logistics operators, at least in Europe. At Euroports, Matthias works in a highly decentralized international environment with multiple entities, joint ventures, local banking relationships, and complex liquidity structures. So the main topic that I would like to discuss with Matthias today is how you bring treasury control into a decentralized organization. If you're interested in cash visibility, centralization, overlay banking structures, treasury technology, and how treasury teams can create impact even without the perfect setup, then this episode is for you. Now Matthias, welcome to the podcast. Can you briefly introduce yourself and tell us about your role?

Matthias: Hey Phil, thanks for having me. I am a treasury professional, working with Euroports since May last year, so I'm pretty new in the role. Before that I worked roughly nine years for Alliance Laundry Systems as an international treasurer — the company is the leading company in commercial laundry equipment. Before that I worked at Daikin's HQ of international operations, which is basically responsible for everything outside of Japan. And before that I also worked at utility companies.

Philip: You look quite young, but you have quite some experience already.

Matthias: I look quite young, but I am actually older than I look.

Philip: And tell us about Euroports. What are you doing at Euroports?

Matthias: I started at Euroports in May last year, and it's basically my role to elevate treasury to a new level. In the past the role was mainly done as a sort of reporting and controlling function — maybe like a treasury controller — so there was more of a focus on controlling. The goal now is to think a little bit more about operational treasury. Some key challenges here at Euroports are around visibility: it's a pretty large group with a lot of entities, more than 100, so there are two main items that are causing some difficulties. On the one hand there's visibility of all those different entities and bank accounts; on the other hand there's centralization, because there's also a limit to what you can do depending on the structure of the entity — is it a joint venture, is it 100% controlled? That restricts somewhat what you can do, or at least what has been done so far. So from that perspective, I think it's important to first have the visibility, then look at centralization, and then, I would say, optimization.

When I joined the company, after I got a couple of weeks of run-in time, what I did was basically build a treasury roadmap — basically: this is where we are, this is where we're going. So, as I mentioned: visibility, centralization, optimization — that was key. And obviously it's directional, not rigid, because something urgent always comes up, or something else has priority. You think of it as a roadmap, but once you're in it, there are obviously priorities on working capital, or a contract needs to be renewed. But that's the overall idea. One other thing I want to mention is that due to some structured financing that we have in place, there is also some limitation on the intercompany flows. That's also something to take into account in finding the proper solution.

And then, to elaborate on the visibility: obviously we have visibility. You have the monthly visibility — every entity does their closing process — and I think we have weekly visibility on, let's say, the Friday positions. Everything is more or less entered manually or sent through the reporting system. What's basically lacking is the daily visibility, because if you only have weekly or monthly visibility, you don't see what happens during the week — you're missing that working capital impact from the week, and that can be very important. For example, if you want to plan an interest payment that happens on a Thursday or Wednesday, then it's important to know what happens during those days. So the daily visibility can always be very important and helpful to elevate your forecasting to another level.

Philip: And Matthias, you mentioned it's a decentralized organization, so 100 different entities. Are you the only treasurer then? Are you the only one trying to centralize? And who are your counterparties?

Matthias: I also have somebody reporting to me, and in one entity there's also a cash manager with different responsibilities. So it's basically just me and my direct report. The counterparties are then basically the local finance directors and local finance managers — depending on the level also the local MDs — and then the CFO, the CLO and the executive committee, depending on whether there is a strategic decision that needs to be approved. And then there are always board reports as well. I think these are basically the main counterparties.

Philip: You mentioned that when you joined the company you made a plan, and you already gave a teaser that things don't always go according to the plan — you have surprises. What were the key things? What was the key challenge in your plan? What did you want to address first? What was number one?

Matthias: Number one was the visibility — having that daily visibility and automating it. Because if cash balances are just entered manually, and even cash forecasts are entered manually, that's fine, but it's a huge strain on the local teams and can lead to errors.

Philip: How many bank accounts are we thinking of? You said 100 entities.

Matthias: I don't know by heart, but 180, something like that. So it's a lot of bank accounts. We're taking it step by step: the easy entities first, trying to get the visibility and improve it with some initiatives. It isn't always easy. There's also change management: people are used to things the way they are, and then you come in and say, "Okay, this is what we're going to do." So it's a little bit touch and go — see where you're going, what you can do. But always try the easiest things first initially. And that's why visibility comes first: once you know, you can take a decision. And then for us, especially in our situation, centralization is key — cash centralization is very key for us. That was also very clear from day one. And then anything else, like working capital optimization and so on, can come later.

Philip: Why is visibility key for you?

Matthias: Because then you can make the proper decisions. If you don't have complete data, then your analysis is largely made on assumptions. If you have daily visibility, you can see the flows. You get to understand the company much better. You can also see where they're holding more buffers, and what actions you need to take. You can analyze that daily visibility, run it through a tool and see: okay, what's possible here? What are we seeing here? You can educate yourself, and you can educate the local teams as well. That's the key: first having the visibility before you actually take these actions.

Philip: Yeah, I completely agree. I think the role of a treasurer is to make sure you have enough cash at the right point in time in the right currency, and the question "how much money do I have now, how much liquidity do I have now" is the starting point of all of that. If you don't have that, or you only have it weekly, you're really trying to take decisions blind, and it makes it really, really hard. So it makes sense. What are the things that you did try then? You go in, your reports show that visibility is the main need, the main topic, and it's not really there — or it relies on the weekly reports that you're receiving. What did you try? What are the key things that you looked into?

Matthias: The visibility is, in our case, obviously very much tied to the centralization. When I joined the company, I think there was also a plan on the table to get that visibility and centralization a little bit, by setting up some local ZBA pools — four or five pools, one in every country — and then basically opening accounts with all those different banks, like a German bank or a Spanish bank: open bank accounts at the finance company and then sweep those amounts to those new finance company accounts. That is already a step in the right direction, but obviously it then requires making those manual transfers. Once you have the funds at the local finance company accounts with those banks, you still need to transfer the funds, and there's always going to be a bit of a local buffer, so there are some limitations. And obviously it was only four or five countries — it was not really a global solution. And you have to take into account that you set up those pools with those local banks, and each bank has their own KYC, requires this, requires that. It's a step in the right direction, but obviously it takes a lot of time, you have to go through different agreements, and legal has a lot of work. So it's easier to think about a more global solution.

And when you think about a global solution, a lot of people think: why don't you go to a global bank and put ZBAs in place everywhere? That is the textbook, standard solution. But you have to take into account that even the biggest banks don't have access to the local clearing in every country. Then they may use a partnership with a local bank, which is always the weakest link — depending on the SLAs, and depending on how strong those partnerships are, that's always the weakest link with a global bank. And specifically for Euroports: it's a port company, and we value the local relationships we have with the banks. They see our presence in the harbor, they want to help, and they have been helping for a long time now. So obviously, as a treasurer, you cannot say: let's just kick everybody out and take somebody else. You have to take into account what's already there, what works and what doesn't work. Taking that into account, the question was: what's possible here? What can we do without disrupting the local business that much? That's basically something to take into account.

Philip: What you're saying is that the textbook step to take would have been to go in, replace many of the local banks with one of the global banks, set up a ZBA structure and move on from there. But you're saying that's not viable in reality.

Matthias: Well, it's not viable — for some companies it will work, but you have to take into account what's possible. A ZBA structure everywhere wouldn't work for us, because with the financing structure we have in place there are limitations on intercompany flows, and with a ZBA structure you always have intercompany loan positions. So for us that's a limitation. And obviously we also have those strong local bank relationships, which we want to keep in place. In that sense, it was easier for us to say: okay, let's not go for one global bank.

Philip: Okay, can you explain a bit more why you have limitations on intercompany positions?

Matthias: It's in the financing structure — basically the senior debt facility. I will not go into too much detail, but it's basically a limitation saying: this is a debt structure, and it is supported by these entities. From that comes a limitation on the flows that can go from the entities that signed on the senior debt — obligor entities, they're called — and there's a restriction when those obligor entities have to send funds to entities that are part of the group but not obligors. It makes sense from a bank's perspective: the debt is supported by these entities, and obviously it's not the goal that there's a huge amount of loans from those obligor entities to entities that didn't support the debt. It's a risk restriction from the bank's perspective, and it's not specific to Euroports — a lot of other companies have the same restrictions. And the fact is that we have entities across the globe, and some entities will never be able to join as an obligor: maybe you don't have full control, maybe there are local regulatory limitations. That's also a constraint that you have to take into account.

Philip: Are you then funding those local entities that are not covered by the main financing structure? Are you financing them locally via the local banks?

Matthias: Some have local structures. Sometimes we can fund them within a certain limitation. It's not the goal for all of these entities to have intercompany loans — that would basically not be possible. So for them it's imperative to be somewhat self-sufficient. That's basically how it's done. But then there are other ways to alleviate this situation.

Philip: So that constraint rules out ZBAs — ZBAs you could not do. So what else did you consider?

Matthias: So, taking into account these limitations — on the one hand the financing structure, on the other hand the local relationships that we have, and then the fact that not every bank can offer everything everywhere — what we chose, or what I basically proposed, was an easier solution: keep the banking structure in place and just put an overlay structure on top of it. You create an overlay structure on top of the local banks through a notional pool — for example, a notional pool here in Amsterdam — and you open local bank accounts for all of these entities with that notional pooling bank, and you just do sweeps from the local banks towards those newly created bank accounts. The benefit is that there's no intercompany position, because if, for example, you have a Spanish entity and you open a new account in Amsterdam, it's their own account — they own it — so it's always a movement within the same entity. You don't have that intercompany piece disturbing them, which is much easier, and with the benefit that you also keep the local relationships.

How it technically works is that you just use MT940s — end-of-day statements — and MT942s — intraday statements. Those are sent from the local banks that are used for the operational payments to the aggregating bank, in this case BMG out of the Netherlands. Then you get the daily visibility, because it's sent out daily. That's one thing: you have that daily visibility solved, and with that daily visibility you can do cash flow forecasting and better analysis. And on the other hand you have the MT101s: you create a bilateral agreement between BMG and the local operating bank, and that allows you to move funds using BMG's platform, from the local bank accounts towards BMG. So basically you have the visibility, you have the centralization, and then on all those accounts in the Netherlands there's a notional pool on top of that. So it has the benefit that everything is taken into account.

Philip: Can you explain — because I think many of our listeners will be familiar with ZBAs, physical pooling and notional pooling, but could you explain it shortly for the new joiners, or for someone who has less experience in treasury? What is a ZBA? What is physical pooling and what is notional pooling?

Matthias: So a ZBA is a zero balancing agreement, where basically at the end of the day you move funds from one account — which is called a participating account — to a master account. Imagine the entity has some funds coming in, and at the end of the day it has a million; that million is then swept to the header account, which is the account where all the participating accounts' funds flow through. This is pretty standard — most banks offer it, with limitations: every bank can offer it in the regions where they have the capability to do so. And you have variations: you can also use target balances, where you would say, I'm not going to move everything out — instead of zero, I'll leave 50,000 or 100,000. That's target balancing, that's a variation.

Philip: So you're physically moving — sweeping — money from one account to the other.

Matthias: Yes. For example, you have a header account in the Netherlands and operational entities in France, Spain, Italy, wherever, all with the same bank, and you set up an agreement that at the end of the day all those funds are swept from those operating entities to the header account — or vice versa: in case the Italian entity is negative, money is swept from the header account towards that Italian account to balance out, to make sure everything is zero. And that's a standard thing.

Philip: And the challenge we were discussing before is that normally the header account would belong to one entity and the participating accounts could belong to different entities, and that would create the intercompany position, which you cannot have.

Matthias: Yeah, that would create intercompany positions. It can be an issue for a lot of entities if these ZBA positions are not properly managed. Imagine you have entities that are not generating any cash whatsoever: they could keep on getting funded and funded and funded from the header account and build up very large positions. What is that position? Is that really still in the spirit of a ZBA? Is that operational, or is it actually more like a long-term loan, and maybe it impacts certain local regulations like thin cap rules? So, to come back to the initial premise: that's the normal setup. Most banks can offer that, with some limitations in the jurisdictions where they can do it.

Philip: What is notional pooling instead?

Matthias: With notional pooling, you have, for example, five different accounts, and the bank takes their balances into account without you needing to physically move them. So if company A has 1 million, company B has 2 million and company C has minus 1 million, then the bank takes into account that the net position is 2 million, and you don't have to physically move anything. But obviously there are also limitations to that. That's basically how it works: it doesn't require a physical movement, which is very convenient, because you don't have that intercompany flow. And it's not just about a financing structure like ours: intercompany movements also require intercompany reconciliation — accountants need to check every month that the bookings are the same, these types of things. Or there could be a limitation with the regular ZBA structure where a sweep is done between different time zones, and it could be that for one entity it's actually already debited but it hasn't arrived yet at the other entity — then you have an intercompany mismatch, and the accountants will not be happy with that. I recall from my past, when I did a cross-regional ZBA sweep structure between Europe and the US, it was: if possible, let's not do sweeps on the last day of the month — to take that issue into account.

So, coming back to the notional pool: you don't have that — it's an elegant solution. What was done with BMG is actually a combination: you have the physical movement — the money is swept from the local operating entities towards the Netherlands — and there you have the notional piece. It's a combination of physical movement and notional aggregation — notional summation, basically. The benefit also is that in this case it's not a regular notional pool but a multicurrency notional pool. Imagine you have different operating entities and operating accounts; they sweep towards the Netherlands, every currency sweeps into a different currency account, and then they aggregate per currency and take into account the value of each currency. You have euros, you have dollars, and the benefit there is that you're not really obliged, as some companies or entities would be, to always do those FX spots: "Oh, we have too many dollars here. Let's just sweep them out, spot them out, convert them to euros." You don't need to do that. The bank knows you have 5 million dollars — that's about, I don't know, four and a half million euros — so it can take that into account. You're removing the constraint that you always have to do the spots and convert dollars to euros.

Philip: You could have a structurally negative dollar position and a structurally positive euro position, and that would be fine. You can keep that going and just pay the interest delta on the notional. Is that right?

Matthias: Yes, but obviously you have to take into account that it's not because you have this multicurrency notional pool that you don't need to hedge. You have to take into account the long-term position, because even though the bank takes into account the value of the dollars and the value of the euros —

Philip: You're still exposed. Of course.

Matthias: Depending on your reporting, you're still exposed. It's easy for the short term, but you have to take into account that in the long term the values of the currencies fluctuate. So it's always good to do your hedging as well. But from an operational point of view, it's no longer: now I really have to do an FX conversion and I don't care if the rate is not good, let's just do it. Those are the annoying things.

Philip: Let me see if I have your new structure straight. You have your local entities with your local banks in the local currencies. With BMG you set up an account for each of these entities in each of their currencies. They sweep the funds from the local entities up to BMG — or vice versa if you have a negative position. Within BMG you have one account per entity per currency, and then on top of that BMG layer you have your notional pooling, cross-currency as well, which allows you on the one hand to get visibility, and on the other hand gives you some flexibility in your FX position on a daily basis. Is that right?

Matthias: That's right. And not only that: because you now have the visibility, imagine you need to do intercompany payments, or need to collect intercompany payments. For example, one entity needs to pay management fees or whatever, and they need to pay a million. Usually, if you request that million to be paid, they can be like: "First you pay us, then we'll pay you." But now, with the notional pool, if you need to do two offsetting payments, you just do them straight away — it's basically left pocket, right pocket. So you also help with that intercompany settlement piece, because it happens within the same notional pool and you don't have the issue. That's also a benefit. And then the final benefit here is that BMG uses TARGET for euros, so the settlement can be done within a couple of minutes.

Philip: You said TARGET for euros — could you explain what that means?

Matthias: Well, TARGET is a high-value settlement mechanism for euros, where you can settle high-value payments in a couple of minutes, whereas a regular SEPA payment could take, depending on the bank, half an hour, or with some banks a couple of hours, to settle. You alleviate some of that fear at the local entities: "We need to be able to make payments, we need to have that buffer, because if we have to make a payment..." — and depending on the entity, the prudence levels are not always the same. Some people reserve a lot, because you never know what happens. But with that structure you can say: just leave a small target balance on the local account, and if you need additional funding, the funds can be settled in a couple of minutes. That alleviates some of that prudency, that fear, and it allows you to reduce those local buffers and have the centralized funds at corporate level, which can then also be used for other things.

And if you want to take it one step further, you can also say: okay, we have all these accounts settled here. You look at the big entities and you say: to maximize liquidity, this large entity does their payments maybe on Tuesday and Thursday, and another big entity maybe on Wednesday, to reduce some of those peaks. If everybody paid on the Thursday, then obviously you would have a big peak. So this is also a benefit of the system.

Philip: And are the local entities doing payments from their local account, or can they do payments from the BMG account directly?

Matthias: No, they do it from the local accounts. This is also because, as I mentioned, the local bank relationships are important. They provide the funding, they provide services. You put a structure on top, but you still allow them to do the operational payments, which the local banks earn on. If you would say, "No, let's just do everything with BMG," and you don't care — okay, the funding is nice, but obviously the banks still take that into account. And there are also limitations to what BMG can do.

Philip: Should we talk about that a bit? You've told us the good things about what BMG does, and you seem to be quite happy. Can you share any of the challenges, or have there been any challenges with BMG?

Matthias: Yeah. You have to take into account that you're talking to a lot of different banks — BMG, but also the local banks. So when you set up that connection, that MT101, you have to take into account within what time frame the local bank can do an urgent payment. For the MT101 to have same-day value settlement — so that when you do the sweep, it arrives on the same day — it's an urgent payment, and the processing time for a local bank can be very different. Some banks will be able to do that until 4 p.m.; other banks will say no, it's only 1 p.m. So there's a limitation there. Ideally speaking, you would want to have the processing time until end of day, but you don't have that. So that requires you, at least for some banks, to keep a local target balance. What happens if you sweep the funds and then there's a direct debit, or a payment doesn't come in? Then you need some kind of buffer. That's the limitation: I wouldn't say not every bank is equally sophisticated, but not every bank has the same processing window. So this is something you have to tweak: you have to see what the limit is and how you do that.

And then the mechanism, how it works: the local bank sends an MT940 intraday statement with the balances towards BMG, and BMG knows: okay, this bank account here has a million. They send that, let's say, 15 or 30 minutes before the cutoff time of the payment processing of that respective bank. Then BMG calculates, and they can sweep. Say, for example, they have a million, and we've agreed on 50,000 as a target balance: they'll just send out 950,000 towards BMG, and you keep that 50,000 in case there would be a small payment.

Philip: So BMG is triggering the payment — telling the local bank: send me 950 automatically.

Matthias: They can do that every day. They can do it up to a maximum of three times a day — and doing three sweeps a day is a lot; most banks do one a day. And besides that, you can also do manual payments with the MT101. Once that bilateral agreement is set up, you can instruct a payment from the BMG platform, from the local bank towards BMG. So in theory, you could also use BMG as a payment factory, where you could do certain payments towards, let's say, suppliers — but that's another purpose here. So that's one of the issues: the cutoff time differences. And your previous question was: do you use BMG for the operational payments? No, we don't. Currently they don't have the capability to handle separate batch payments — otherwise you could say, let's do the operational payments from BMG. They don't have the capability yet to process batch payments for vendors or suppliers. That's not possible, and I don't think they're launching that next year either — I didn't get a target date on that.

Philip: So that would mean you would upload your batch, your payment run, in BMG, and BMG would delegate that to the local bank: "Execute these payments on my behalf." Is that how you would see it?

Matthias: Yes. But what I mean basically is that with BMG, BMG itself would also do the operational payments.

Philip: From its own account, you mean.

Matthias: Yeah, okay. Yeah — and as I mentioned, for some entities you could do that, depending on the relationship with the banks; for others you can't. That's a limitation.

Philip: No, understood. And how long does the setup between BMG and the local bank take? Because the cornerstone is the relationship between BMG and the local bank: you need to set up the MT940 flow — the bank statement flow — and the payment flow as well. How long do that paperwork and that process take?

Matthias: It depends on the local banks, basically. Some banks are very quick to set that up; other banks can take several weeks, depending on what they require. Some require a red-ink signature. Most banks have their own documents to sign. So you have the paperwork, but you also have to have the agreements, because even if they send an MT940 with the balances, BMG needs to be able to interpret it. And the funny thing is, in that MT940 you have a tag 25, where the bank account of that respective local operating bank account is mentioned. Every bank seems to have a different way of putting in the IBAN number: some put the IBAN number, some put the IBAN number plus "EUR", some put the IBAN number directly followed by "EUR". So — and this is also a funny thing — you always have to ask: what did you put in your tag 25? Because then BMG can recognize the incoming statements. That's a technical thing. Basically it varies, and for some banks it can take quite some time.

Philip: Can you give us a bit of an idea of how long the project took, for how many banks, more or less?

Matthias: That's still ongoing. For one bank it takes maybe a week, a couple of weeks. But purely the connection with the banks can take a month, two months — that's for sure how long it can take, assuming you have the internal paperwork signed with BMG; that's all nice and fine, but it can still take a couple of months. You also have to do penny tests: once the MT101 is set up, you do a penny test, making sure everything arrives on the same day, everything has properly arrived, and there are no additional fees on those transactions. So it's paperwork and also technical setting up. And then: different banks, different languages. Sometimes you have to speak in multiple languages, because this is pretty technical stuff, and some banks will be very familiar with it, others will not. Local teams will maybe not be familiar with it and need to bring in the local specialist, and you want to avoid stuff being lost in translation. It's always good to be able to translate that into different languages, to make it as clear as possible.

Philip: Now that the project is ongoing — and I understand you're quite far ahead — is there something that you know now that you wish you had known at the beginning? What would you do differently from the beginning?

Matthias: BMG proposed using a standard template, which basically says: we're the company here, we're doing cash management centralization, this is what we're doing — MT101, MT940, MT942 — and we had to get that signed by the local directors at the local entities. I think there were maybe one or two banks that accepted that, and everybody else came back saying: "No, no, no, you have to use our format, and this and that." And you have to be very clear, because sometimes there's one form for MT940s and 942s and one for MT101s. You have to be very clear: it's only within SWIFT — you have FIN, and there's also FileAct — it's only FIN, that type of thing. Now, I would have just reached out to the banks, asked them to provide their own template and had that signed, because now it's a double signing. But coming back now to the limitations — unless you want to ask another question first?

Philip: No, it's okay, go ahead. I have plenty of questions, but please continue.

Matthias: Another thing is the MT101 cost. Depending on the bank, it can be very expensive. We had one bank that charged €53 per MT101 payment, and the local entities were like: "Wait, we're not going to pay that. If we do that times 220 days — Jesus." So in that perspective we had to shift gears. We said: okay, we're not going to do that every day, for sure. And then I came up with solutions. Basically: we have some factored funds — a factor currently paying into certain accounts. We'll just have the factor pay into the BMG account of that respective entity. They receive those funds all the time, and the sweeps will then only — or most of the time — go from BMG to that local bank, because otherwise it would not have been feasible. €53 per day...

Philip: Per account, per transaction. So that would have been too expensive. But that way the local bank also lost out in a way, right? Because then all the funding goes straight to BMG, and the liquidity is not staying on the local account anymore.

Matthias: True, but they wouldn't have had the liquidity anyway, because we would have swept it at the end of the day anyway. They still have their own transactions — they earn on the transactional payments. So they still have that.

Philip: In that case, making payments from the BMG account operationally would save quite some money, because already today you're paying €53 on those local accounts, isn't it?

Matthias: Yeah, you could also do that, but as I mentioned, they don't have the capability to do the separate batch payments.

Philip: But maybe another advantage of the setup that you did could also be when negotiating with the banks — it does give you some leverage. I can imagine that you could go to a bank next time you need to renegotiate fees or funding or whatever, and the fact that you have BMG does give you some credibility on alternatives. Or is that something you don't consider too much?

Matthias: Yeah — one of the side effects of this is that you have the visibility, you have all these different accounts, you have the data. Once you have the data, you can see the charges: what are the maintenance charges here, what does every bank charge? Once you have the data and you connect it to an analysis tool — and especially with the tools that we have today — you can easily do an analysis on the historical data and see: what are the maintenance fees here for bank X versus bank Y, and compare that. It gives you a lot of leverage, because you have the knowledge. And from a corporate level it also shows you: why do we have all these bank accounts here? Because at the local level, treasury is not going to be put first — there could be various reasons why they have local accounts — and after a couple of months you can say: these accounts here — nothing happens on them, we pay fees on them, why are they still needed? And, as you say, you can also compare, and wherever possible you can ask: what are the alternatives, what can we do? Coming back again: it's the visibility, not just on the balances but also on the fees that you have. And once you have the visibility, you can do the analysis, and then you can take the decisions.

Philip: I had one question regarding your implementation. You mentioned MT101s and MT940s, so payment initiation and bank statements. Why are you relying on the MT messages and not moving to the camt XML formats?

Matthias: It's still the most supported way of connecting with most banks. I think you could do camt as well, but for now this is still the way you can connect to most banks, and it's also what they offer as standard. In the future it will probably be different — it will be more the camt XML ISO solution. But for us, especially if you want to add banks from outside of Europe later — now we're doing Europe — the MTs are still the best for now. And not only that: for us specifically, our accounting system is still best suited to read MT files, not camt files. So initially I thought, let's see what we do, but for now it's just the path of least resistance, and then we can see how we can tweak it. Obviously with the camt files you have more characters — it's going to be better for reconciliation. But for now this is the way we move forward.

Philip: To recap and take it from there: so in practice you see that MT messages are still here to stay — still the default for today. Everyone speaks about camt XML, but still uses MTs as the default.

Matthias: It can still change. And for a regular bank statement that you download to your ERP, I think you can already use camt to get those statements. But for the communication between the banks, I think it's easier to do the MT format for now — I guess that will change in the future.

Philip: Okay. And then, we've been talking about BMG for quite a bit. Some would argue that what you're doing with BMG you could have managed with a TMS. How do you see that?

Matthias: Yeah, some of the elements you could do: target balancing, for example — that's a key thing with a TMS. We currently don't have a TMS yet, but you could do target balancing, where you connect several accounts. But you could not do the notional pool — for that you need a bank. A TMS cannot offer a notional pool; it's just a piece of software. I think at some point in time we'll definitely integrate some of the TMS elements, because one of the restrictions I forgot to mention on BMG is that they can put target balances on the operating accounts, but they cannot do target balances on the BMG accounts. If you wanted an automated solution, you could say: let's just do a sweep on Thursday and Tuesday from BMG to the local operating entities to fund them — we have a million, let's just keep 100,000 at BMG and move everything out. That's not possible. So now what we have to do is ask the local entities how much they would need — what's their funding requirement? But it's not because they say they need 2 million that there will be 2 million on the BMG account. So you initiate a sweep for 2 million, there's only 1.5 million left on the account, and the sweep doesn't go through — you have to take manual action. So, to take it to a more automated level — and I'm not saying we need that for every account — you could automate it and say: we just keep that amount of money at BMG, and then it's automatically done. So this could be a benefit of having a TMS connected to those BMG accounts as well.

Also, depending on the TMS, some TMSs have the capability of creating a BIC SWIFT address for your company, but that costs money as well, to send those payments or messages out. Some TMSs use EBICS — a format originally from Germany — through which you can also send out messages and payments. But there's a limitation, because that EBICS channel is, from what I know, mostly used in the Netherlands, Belgium, Germany and France, and wouldn't be applicable in the southern European countries. So for me it would be a good add-on, but obviously it could never replace the notional pool that BMG offers. So for me it's not a full replacement.

Philip: And when you started the project with BMG — before that, did you consider a TMS as an alternative from the start? Did you say: okay, we don't want a TMS, we don't need a TMS, we go straight with BMG?

Matthias: It's prioritization. Visibility and centralization were the priority, and from that perspective I thought BMG was the best solution, because then you also have the notional pool effect as well. It's a cash management bank — connecting with other banks is their bread and butter, that's what they do — and the goal was to connect as many banks as possible and have that notional aggregation, which a TMS could not offer. Sometimes you have to choose.

Philip: And did you make any analysis from a cost perspective of how much the BMG implementation costs you compared to implementing a TMS? Or did you not even go as far as that?

Matthias: No — we did check how much BMG costs and how much they charge. I did check on TMSs, but from a general perspective, because we are also considering a TMS for the long term. But sometimes you want to move a little bit faster, you have to choose between one or the other — and it's not exclusive. For me a TMS wouldn't be able to fully replace this structure, so I wouldn't have considered it a full alternative.

Philip: And do you expect to implement a TMS one day in the future, or are you okay running as you are now?

Matthias: Well, visibility is a key point. Once we have the data, we connect a new cash forecasting tool to it and get the analysis, and then we'll add TMS modules or requirements. We're not going to add everything, but, for example, that target balancing on the BMG accounts could be useful; intercompany loan calculation, interest calculation; and we'll take a look at FX as well. So there's a lot of stuff we want to do, but it always depends on the priority: just take part of it and move that forward. But yes — the visibility, then build your centralization: that was the first priority.

Philip: So you're basically building your own TMS in house, with different bits and pieces, building as you need. Is that your approach?

Matthias: No — we're looking at a cash flow forecasting solution. That's the most important thing: connecting the data of BMG to a cash flow forecasting solution. Then I identify all the functionalities that we want, and we see if that can be done through the cash forecasting solution. If not, we'll get another solution to provide those features.

Philip: I see.

Matthias: Yeah.

Philip: And before, when we were talking about bank fee analysis, you mentioned something like "all the tools that we have now". I guess you were hinting at AI?

Matthias: The cash flow forecasting tool would then also have AI capabilities, and you would analyze the transactions — the transactions that are passing through your accounts. Once you have that access and visibility, you can, to a certain level, do an analysis of what fees are charged, without having to get all those agreements from across the globe — which you will never get anyway, or not all of them. You can just analyze; you can do a search on keywords like "maintenance fee" or "transaction fee". It's never going to be perfect, because some transaction fees, for example, are charged directly on the transaction, but you can teach AI that and then you can make the analysis. It's not a priority, but once you have the visibility, it's a nice thing to have to draw those conclusions.

Philip: And is that the AI tool within your forecasting tool — the forecasting tool that you plan to implement?

Matthias: Yes. So basically it will be BMG connecting to that cash flow forecasting tool; once the data is there, the analysis can be done. That's the beauty. But coming back: building up treasury is always step by step. It's not really a big bang, and you have to take into account that you also have the operational stuff that you have to do — it's not only project work. So it's step by step.

Philip: And do you see a role for AI in general in helping you with those operational things? You're a young — well, not-so-young — treasurer. So are you using AI? How do you see the role of AI in treasury today?

Matthias: I think AI can be very useful for pulling out what you don't know. If you provide it a lot of data, specific good context and certain guardrails, there's a lot of stuff you can do. It can draw conclusions, make forecasts — you still have to check. But if it can analyze historical cash flows, predict the future, review patterns, I think there are a lot of capabilities there, especially for cash flow forecasting, but for other use cases as well.

But I wouldn't say AI is the only recent thing. There's also API connectivity — a lot of opportunities there as well, especially for us, and for a lot of companies: make an easy connection, get FX rates, daily bank statements, do FX hedging. So there's a lot of room for improvement there as well. And you always have to take into account: anything is possible, but everything needs to be paid for. It's not that treasury has a huge IT budget, so it's always good to look for these quick wins.

Philip: Yeah. So actually, with APIs, that in theory could be an alternative as well, right? You could use APIs to get cash visibility from all your local banks and build a reporting layer on top. And if you were to have payment initiation by API, you could build your own BMG structure in house if you wanted to.

Matthias: Yeah. Without the notional pool, right?

Philip: Without the notional pool, that's right. What is, in your experience, the readiness of the APIs of the different banks? We've been hearing about it for the last — I don't know — 10, 15 years: APIs here and there. I can give an example: I've had quite some experience with banks who will say, "Yes, we have APIs, of course." Then we start implementing, and it feels like I'm the first person ever implementing that API. As you see, it's really not ready: it gives back responses that are far from the documentation, or things just don't work. What is your experience there with APIs?

Matthias: Yeah, I think the maturity of APIs very much depends on the different banks and how much they invest in it. Some banks say, "We have APIs," they show a demo, but that's about it. But other banks have a developer platform: this is, for example, what you need to do, and if you can do a little bit of coding, you can do it yourself. At the previous company I was able to set up three APIs myself, completely, just for reporting and executing FX hedges. It gives you some tools in your hands, where otherwise you have to go to IT and say, "Build this up." Obviously you still need some support from IT — for example, to whitelist IP addresses, which you cannot do yourself — but there's a lot of API connectivity, a lot of room to automate and get those data flows in. But coming back to your initial point: could that replace BMG? No, because of the notional pool, and also because a lot of banks don't have that full API connectivity. It's not really standardized: every bank is different, they use a different protocol, a different method. So it depends. From my perspective it was better to have everything with BMG, the data there, and then make one connection towards the cash flow tool. We could also have said: let's connect 30 banks to the cash flow tool. That would have been a complete nightmare: every bank would have a different connection, depending also on how sophisticated that vendor is — can they build the connections? With BMG, I know that's what they do: they build the connections, that's their job. A lot of tools these days are focused on the AI, but the connectivity piece can be a nightmare. So that's why I said: let's do BMG. They know how to connect with other banks — it's what they do. And then once you have the data there, let's just connect that data. One simple connection — we're not even using an API, we're using SFTP.

Philip: Yeah, that sounds like a reasonable and practical approach. I actually still have one question — we have many questions, but we're using a lot of our time already, so I'll keep it short. You mentioned you built APIs at your previous employer. What were you using — Excel, VBA, Python? How did you do it then?

Matthias: I used a combination. I also didn't have a TMS there, so I basically used VBA and PowerShell to connect an Excel to an API, and that was for doing FX hedges and creating a full data audit log of the transactional flow. I also did it for collecting payments — collecting retail payments. Basically, I provided an Excel tool — and this is more proof of concept — for the collecting of the payments. Once you have that capability as treasury, to convince somebody you can just make an Excel tool, build some buttons and some macros, and they can just send out an email with small payment requests to customers that need to do ad hoc payments. It's easily done, it's a proof of concept, and when you want to centralize or industrialize it, you can always look at integrating it — actually pay the money to SAP or the SAP consultants to build that out. But I think, if you understand the APIs, you can build the connectivity as a treasurer. You have a lot of tools in your hands to create value without having to request the funds — because otherwise you have to request the budget, it has to be approved. This way you can easily do a lot of stuff by just connecting what you have. So I think that's it: let's get it going.

Philip: Try it. See if it works.

Matthias: Yeah.

Philip: And get going. Have you ever used Power Query in your work?

Matthias: In Excel? No. Actually, no.

Philip: I think you will like it. Power Query is the engine behind Power BI, and Microsoft put it in Excel as well. It's really useful, really powerful. Hardly anyone knows about it, but based on what you're telling me — you're building things with VBA — you will love Power Query. Google it; there are a bunch of YouTube videos about it. I think you will enjoy it. Thanks for all these insights. I have one last question for you, and it is becoming a tradition on this podcast: the one thing tradition. I'd like you to summarize in one minute: what is the one thing you would like to tell a treasurer listening, and especially a treasurer who wants to have an impact in his or her organization? What is your one thing, Matthias?

Matthias: I would say, based on everything I told you: fit the treasury architecture to your existing company structure, and not vice versa. Don't try to push a structure onto the organization — do it the other way around. As I mentioned, textbook-wise we could have gone with a global bank and ZBAs. That would not have solved everything — it's not always the right answer. You have the structural constraints; you have, in our case, valuable local banking relationships. It's very important to take those local relationships into account and respect them, because the business depends a bit on them. And it's not because treasury has a new tool, a new way, a new method, that it will be appropriate for your organization. You need to find a structure that matches, and the trapped cash will then surface along the way if you properly adapt the architecture to the business structure.

Philip: Well, Matthias, thanks a lot. It has been a pleasure to have you on the show. I really enjoyed the conversation. For people who want to reach out to you, where can they follow you — LinkedIn, anywhere else?

Matthias: Yeah, LinkedIn — I think that's probably the easiest. I'm easy to find on LinkedIn, so happy to answer any questions.

Philip: Thanks, Matthias. Take care.

Matthias: All right. Thanks for having me, Phil. See you. Bye.