The vision of managing a corporate treasury in real-time has been around for almost a decade. In Europe, the introduction of SEPA instant payments in 2018 first put the term on the agenda. However, it was only recently that real-world applications moved beyond ‘nice-to-have’. So, how can real-time treasury be approached in practice? What are the building blocks and how can treasurers get started?

These questions were discussed by a panel at the Finanzsymposium, an event for corporate treasury professionals held in Wiesbaden (Germany) from 7 to 9 May 2026. This article summarises the discussion, focusing on three main issues:

• Connectivity and application programming interfaces (APIs);
• virtual accounts; and
• global liquidity management, including challenges in regulated markets.

Panellists (left to right): Renato Barbone, Jörg Bermüller; Gherri D’Innocenzo, Martin Priebe

Martin: Real-time treasury means different things for different people. So, to start, could you please briefly describe your view on the term?

Gherri: For me, real-time treasury means having cash available where it's needed, anytime, 24/7.

Jörg: For me, real-time treasury isn't necessarily about seconds; it’s about having access to comprehensive, timely information that I can act on. Just having information quickly for the sake of it doesn't help. We want to use data to trigger a process.

Renato: It's difficult to add to that, but for me, real-time treasury completes the basis for decision-making. It provides higher transparency, better knowledge, and ultimately enables us to make better decisions.

Martin: APIs are often regarded as an enabler for real-time treasury – and we see that they are becoming a more widespread connectivity channel. It often starts with real-time account balances and statement reporting. However, APIs can also be used for payment initiation and automation. Siemens is quite advanced in this area. Gherri, why is Siemens interested in API-based payment initiation?

Gherri: We decided to implement APIs a while ago. We wanted to experiment with new payment rails but also wanted faster information. APIs allow us to access the bank's ecosystem directly from our treasury management system (TMS) so that we can immediately track the finality of a payment within our system. Once this was achieved, new use cases emerged…

Martin: … which were driven by the removal of amount thresholds on SEPA instant payments in October 2025, right?

Gherri: Indeed. At Siemens, we have developed specific products, such as 'Pay-Per-Use' models for engineering software, which require instant payments – and more generally, event-based trigger payments. Going forward, our products will include payment functionalities, meaning that upon activation by our customer, or any other event we define, a payment is triggered. This event could be anything – a specific time or an account balance, for instance.

“We use payment triggers to fund our accounts globally, ensuring cash is available 24/7”Gherri D’Innocenzo, Head of Cash Management and Payments, Siemens

Martin: Could you elaborate a little on how you envision using trigger payments? What are the use cases?

Gherri: There are two main areas – one within treasury and one from the business. The first is liquidity management, where we already use triggers to fund our accounts globally, ensuring cash is available 24/7. We have defined corridors, and if account balances go above or below these corridors, a payment is triggered. Depending on the rules – which consider for example interest rates and market conditions – money is transferred or invested. Second, we look at embedding payment functionalities in our products as explained earlier. APIs enable us to offer 'Pay-Per-Use' or 'Pay-Per-Time' models.

Martin: Jörg, Merck also uses trigger payments. What was your approach?

Jörg: Ours was different. We don't use APIs yet; but are currently exploring them. So, what did we do? We analysed the account statements of our 400 subsidiaries, looking at incoming and outgoing cash flows. We identified patterns such as payroll or recurring supplier payments. Then, we set a daily target balance for each account, which will lead to zero balances locally.

In the next step, we used the fact that our TMS can trigger payments. For example, we defined the following: If 500 Czech koruna are in an account in the Czech Republic, the system automatically creates a payment file – that will be executed cross-banking, based on our time schedule and in the respective amount. This means that we have converted our global payment factory into a bank-independent cash pool engine. Liquidity disposition is done by our treasury system landscape. The team only monitors whether it worked.

“Liquidity disposition is done by our treasury system landscape”Jörg Bermüller, Head of Cash and Risk Management, Merck KGaA

Martin: That's impressive, and we know from many client discussions how time-consuming and labour-intensive liquidity disposition can be, especially when multiple currencies and banks are involved.

Gherri, you've invested a lot of resources into setting up your trigger database in-house. What were your considerations for developing this internally versus using external service providers or banks?

Gherri: This is not an either-or-situation. We also use solutions from banks if they have better information, for example, for automated funding of a specific account when we process payments. We don’t need to programme these bank-sided triggers ourselves. However, there are events that only we know about. If a customer activates our software, the bank cannot know that something needs to be paid so we relied on developing our own customer-side triggers. Both complement each other.

Martin: For us as a bank, quite a provocative question is whether our customers will still need a cash pool from us in the future or if trigger payments remove the need for pooling. At the same time, we want to encourage you not to shy away from trigger payments. Companies do not need to build their own trigger databases from scratch to benefit from real-time automation. It can be an iterative process. And as a bank, we want to support you in getting started on this path.

Martin: Renato, speaking of automation. Bayer has established a fairly advanced in-house bank structure. At the end of 2024, you made a strategic decision to use virtual accounts as a central element in your in-house bank. What was the starting point for you on this journey?

Renato: At Bayer, we are currently in a major S/4HANA rollout. As part of this project, treasury was approached by the project team and by customer service departments, pointing out that we have multiple physical bank accounts across the group, used for various purposes. A request for the project was whether we could provide bank accounts that were somewhat cleaner, meaning they might only receive customer payments in currencies A, B, or C. This initially caused some discomfort because the immediate thought was, 'How many new physical accounts do we need to establish this segregation?' And that’s where virtual accounts entered the game.

“Virtual accounts are not rocket science, they are just smart treasury”Renato Barbone, Lead Cash Management, Bayer

Martin: Where have virtual accounts brought you the greatest added value? And where might they not be a panacea?

Renato: Let's be honest, virtual accounts are not rocket science; they are just smart treasury: a relatively simple medium, but with high utility. Virtual accounts allow us to reduce costs and documentation needs associated with underutilised accounts; they also improve control and reconciliation. But there are still some scenarios where a physical account is needed, or where one would rather opt for a physical account in case of doubt. A tax payment in Spain for example remains complicated. An advantage which I did not have on my radar before was that virtual accounts encouraged us in treasury to think differently about requests from the business.

Martin: Could you give an example?

Renato: There are various scenarios where I believe we in cash management might not have shown full readiness for compromise – not due to bad intentions, but because of a 'wagon-fortress mentality' in treasury. Virtual accounts have reduced some barriers. When I'm contacted now, and there's a desire for an account in currency A or B, I'm more open to it because I don't have to worry about the workload it might generate. I think this psychological aspect should not be underestimated. Ultimately, we are an enabler for the business.

Gherri: At Siemens we also see the benefits of virtual accounts. We are converting existing physical accounts into virtual accounts, which means that our customers will not notice the difference because they can continue paying to the account they know. Virtual accounts mitigate the risk of fraud and help us centralise liquidity. We don’t need to transfer money at the end of the day because it is already consolidated on the physical account level in real time.

Martin: This brings us back to the question: do we still need cash pools in a real-time world? With virtual accounts and trigger payments: no. Jörg, what's your take on this? Merck is always at the forefront of treasury innovation. But when it comes to virtual accounts, you are somewhat reserved. Why?

Jörg: Virtual accounts have been around for more than a decade. We keep checking their relevance, but for us, they are not the game changer. We do see their advantage for reconciliation, but reducing the number of accounts is not a business case for us. Each of our 400 subsidiaries ideally has one account. And as we sell locally, we know that when a payment comes in on the French euro account, it's from a French customer. This helps our shared services centres handling the reconciliation. And for centralising the liquidity, we have cash pools and implemented trigger payments as explained earlier.

Martin: Renato, where else do you want to go with virtual accounts? What's on your agenda and roadmap for the next six to 12 months?

Renato: We will continue to align ourselves closely with the S/4HANA project. It has a geographical rollout plan, which we will follow step by step. It starts with Europe, continues in North America and then expands to Asia. But that’s not the end of the journey. We have a few more ideas I cannot divulge yet.

Martin: Let’s move to another issue that many treasurers struggle with and where moving to real-time can deliver tangible benefits: managing liquidity in regulated markets. Jörg, Merck has done quite a lot of work to integrate global cash into your in-house bank and convert and pool everything in euros by the end of day. How does that work in regulated markets?

Jörg: It’s tricky. Let’s take Japan as an example. The market is not regulated, but the eight-hour time difference to Germany made it difficult for us to include the money from our local subsidiaries into our in-house bank. This means that money was kept in Japan and did not earn interest. We then sat down with Deutsche Bank and looked for solutions to transfer money T+0 in both directions, by leveraging Deutsche Bank’s technical infrastructure.

The new process now looks like this: we have an end-of-day closing in Japan, with surplus transferred to Frankfurt. A FX deal is triggered converting Yen into euros value same day. If the local account is in deficit, a FX deal is triggered, the euro account is debited, and JPY are credited at the end of the day in Japan. We can monitor this process via an API: that’s where we really see a benefit in APIs and want to roll it out to other countries as well.

“Real-time treasury can achieve far more with today’s infrastructure than most assume”Martin Priebe, Head of Cash Solution Sales MNC Germany, Deutsche Bank

Martin: And you can probably attribute an interest effect to T+1 versus T+0 quite well, can't you?

Jörg: Exactly, that's the beauty in treasury, it's about numbers.

Martin: This shows that real-time treasury can achieve far more with today’s infrastructure than most assume. Jörg, I'd like to look at India as well, where Merck was one of the first companies to make use of a regulatory easing. Since February 2025, the Reserve Bank of India allows Indian rupee (INR) accounts to be held offshore. What's your perspective on this?

Jörg: We jumped on this immediately because we were convinced that it will support our in-house banking approach. Now our in-house bank has an INR account in Frankfurt. As one of my team members said, “We converted the INR to US dollars.” Meaning that for us, the cash disposition and hedging process for INR is the same as for USD: money is automatically transferred to our in-house bank and sold via FX-All. Therefore, we don’t need to hedge with non-deliverable forwards anymore. On top, we reduced hedging cost, centralised cash and automated reconciliation.

Renato: For Bayer, I can say that Indian rupees are clearly on our agenda too. When I look towards Asia and see how many conversion payments we have in these countries, that's something we need to change. We just have too many hidden costs and also less control over what happens with cash flows.

Martin: To sum up, let me ask three short questions. First, what is a real-time capability that you would not want to miss out on?

Gherri: Definitely APIs and virtual accounts.

Jörg: Near-time access to comprehensive data.

Renato: I can only fully support that. As we said at the beginning, the level of transparency and autonomy, and the information we gain from it.

Martin: Second, what is a myth about real-time treasury that we should bury?

Renato: Real-time treasury can't exist everywhere. It all has limitations.

Jörg: That it makes everything better and allows you to manage a treasury with less manpower.

Gherri: That everything could happen at any second, at any time.

Martin: Third, what advice would you give to fellow treasurers regarding real-time treasury?

Gherri: Start with a small building block somewhere and see if it helps.

Jörg: It doesn't happen overnight. Listen to your employees to see where the challenges are and give them the freedom and time to try things out.

Renato: Go from the known to the unknown. Create simple use cases that can actually be implemented, then learn from them and gain acceptance.