Programmed for Success

Published: April 10, 2024

Download this articles as a PDF
Programmed for Success
Eleanor Hill picture
Eleanor Hill
Editorial Consultant, Treasury Management International (TMI)
Heiko Nix picture
Heiko Nix
Head of Cash Management and Payments, Siemens
Naveen Mallela picture
Naveen Mallela
Head of Coin Systems, Onyx, J.P. Morgan
Tilmann Dengler picture
Tilmann Dengler
Head of Corporate and eCommerce Sales, Austria, Germany, Switzerland and the Nordics, J.P. Morgan Payments

Siemens Leverages J.P. Morgan’s Automated Blockchain Payments

Programmable payments are not just a neat demonstration of the power of automation, they can also be a foundation stone for the development of real-time treasury.

In December 2021, J.P. Morgan and Siemens tested a new ‘first-of-its-kind’ automated treasury solution called programmable payments. The trial system was facilitated by the bank’s earlier development of its Onyx technological infrastructure, a blockchain-based platform for payments transactions.

By combining these technologies, and then applying them to a number of real-world pain points, Siemens now had access to a groundbreaking automated payments tool using pre-programmed rules that initiate a response to events, in real-time, whenever certain conditions are met.

The programmable nature of these instructions removes the need for human intervention before a payment can be executed. This means much faster transactions, potentially resolving a common liquidity problem for many businesses: assigning excess liquidity buffers during periods of international cut-off times, such as weekends, bank holidays and overnight.

By enabling this cutting-edge payments capability to be embedded natively into business processes, Heiko Nix, Head of Cash Management and Payments, Siemens, described this new technology at the time as “one of the foundations for developing a real-time treasury at Siemens”.

Skip forward to November 2023, and Siemens had just become the first J.P. Morgan client to use the programmable payments functionality of the JPM Coin System in combination with the bank’s blockchain-based bank accounts. “This will take Siemens to the next level of automation to not only optimise the use of working capital but also enable data-driven digital business models and support the scalability of our Siemens business from the treasury side,” Peter Rathgeb, Group Treasurer, Siemens, commented at the announcement.

As we move into 2024, progress in the programmable payments space is gathering pace, and both J.P. Morgan and Siemens’ pioneering approach continues to make waves. But what role might this technology have within the wider treasury realm?

Starting points

“What we have built is an account system far removed from the traditional approach because the new system enables us to set conditions, where the sky will be the limit,” says Tilmann Dengler, Head of Corporate and eCommerce Sales, Austria, Germany, Switzerland and the Nordics, J.P. Morgan Payments.

To further explain, Dengler says that a classical account system enables only limited conditions to be set, such as a repeated transaction date. Holders of a brokerage account can set a stop-loss to limit risk, for example, but again, the variety of rules and usable data are “extremely limited”.

This goes a long way to explaining the effort applied by J.P. Morgan to its programmable payments project. Creating a system that is based on the programming idea of ‘if this, then that’ (or IFTTT), and enabling access to the bank’s own data and, eventually, external sources, is a powerful proposition.

As an example of a ‘data event trigger’, Dengler says that when a transaction from one account drops below a predetermined level, the system can be set to automatically shift the appropriate sum from another account to prevent that shortfall. In another example, using external data points, trading partners may be alerted to a suitably tagged shipping container being loaded, and then leaving the harbour, with the system triggering payment for the confirmed in-transit goods.

For Siemens’ Nix, it’s important not to view the notion of programmability in isolation. He argues for the “triad” of money, rules, and data. This triad, sometimes referred to as a smart contract, may draw data from internal corporate, banking or third-party sources. But, he insists, “it is this source that will determine the use case, not its programmability”.

To illustrate his point, Nix explains that bank data, such as a bank account balance, can be used to automate Siemens’ operational cash management. But he feels there are many more opportunities in waiting. But with pay-per-use and machine-to-machine payments in vogue currently being only “discussion topics”, Nix believes these models could achieve far wider adoption when the essential ‘money, rules, data’ triad is available and ready to leverage, while emphasising cryptocurrencies are currently not needed for such use-cases.

 Once a point of maturity has been reached in this market – and here he notes J.P. Morgan has taken major steps towards implementing the pre-conditions to facilitate smart contracts – pay-per-use and other such concepts will begin to flourish.

Behind the scenes

The aim of natively connecting accounts, data, and rules within the programmable payments system is to provide “coherence guarantees”, says Naveen Mallela, Head of Coin Systems, Onyx, J.P. Morgan. Similar to the concept of atomicity in the crypto world, this essentially creates a mechanism ensuring that each technical component is indivisible from the other, where usually they are separate and distinct, so that the whole functions “consistently and stably”.

Atomicity drives the creation of almost limitless payment possibilities via the rules-based approach. And while it also opens up the notion of who sets those rules, Mallela notes that J.P. Morgan’s work with Siemens has, from the outset, been framed by a desire to make the programmable payments interface as intuitive as possible.

The initial outcome of the quest was a Scratch-like interface. Scratch is a block-based (or ‘drag-and-drop’) coding tool that has been optimised for beginners, and is also frequently used by game programmers. However, with the Siemens team finding that this approach created too many gaps to be fully usable as an automation tool, the next step gave rise to the IFTTT structure, with fully native components, based around a DLT bank account. This enables full smart contract creation.

Explaining the drivers for achieving coherence guarantees, Nix offers the analogy that when issuing a bond, it is essential that at the exact time ownership is transferred, the funds are received. This ensures that in a delivery versus payment (DvP) scenario, the funds and title are simultaneously and irrevocably assigned. “It’s like the two sides of a coin; they can’t be separated.”

Spot the difference

As with many pioneering works, the teams from J.P. Morgan and Siemens started with a number of ideas, but not all were pursued to completion. “We knew that not only could it be difficult for a treasurer to start programming but also that the programme itself had to run exactly as expected every time, because we’re dealing with company money,” comments Nix. All perceived risks were thus mapped meticulously so they could be avoided.

This is why Mallela’s team created programming templates that were pre-tested and pre-validated. It’s also why, with the Siemens treasury team having increased accessibility to its accounts, there are no differences between its physical accounts and the Onyx DLT versions.

“Every requirement that is fulfilled by us in the fiat currency world has been transferred into the blockchain world; there is no difference,” states Nix. “Now, whenever an auditor questions the difference between the fiat and blockchain bank accounts, we can say they are identical, and that transactions on our Siemens Cash Management system look the same and work the same. We worked hard to avoid any downsides.”

Just a few years ago, the discussion about on-chain money was centred around crypto, says Mallela. “Now, it is more or less established that crypto as a payment currency is not going anywhere, that stablecoin still has a way to go to viability, and that CBDCs are yet to properly materialise. With most payments today made using commercial bank money, we don’t see that arrangement changing in the world of digital currencies any time soon.”

Indeed, he believes commercial banks will retain their significant role, especially as systems such as JPM Coin gain ground. “We don’t want clients grappling with new accounting treatments and legal opinions, so we have deliberately stayed within the product boundaries of the deposit; what we have introduced is a new sub-ledger.”

This new book-keeping system gives greater accessibility to its stakeholders. Traditionally, clients had to approach their bank to establish a channel though which they could access their accounts. This might be via a banking portal, an API, or through Swift, for example.

But now, explains Mallela, with a DLT-native bank account such as the JPM Coin system, “the bank account comes to you”. The next step being considered by the J.P. Morgan development team is to “externalise” the account, he says. “Technically, a corporate could host a node in its own data centre, holding its accounts natively, so there is no need to rely on the bank or a specific channel for access”.

Why it matters

One of the key drivers for the adoption of programmable payments at Siemens, says Nix, is the increased opportunity for automation of operational (as opposed to strategic) liquidity management. Another reason he cites for taking this path is treasury’s lack of confidence in forecasting quality. “Precision is really difficult to achieve. If we accept that fact, we can do away with cut-off times in our bank accounts, allowing 24x7 payments, because we can react as they happen using automation, therefore eliminating the need for operational liquidity forecasting.”

These are important considerations for most treasury departments. Dengler acknowledges that being able to predict cash flows in specific accounts and currencies is extremely difficult. “Accepted forecasting inaccuracies often impose the need for liquidity buffers. But even unexpected incoming payments create disruptions in cash flows; it’s why businesses are forced to keep several people busy just controlling their account balances,” he says.

“But if we introduce programmable payments, specific accounts can automatically be refilled when there is a trigger event; for example, a low balance. That frees up a lot of liquidity because the business no longer needs cash buffers, or the personnel to monitor its accounts day and night.”

As an additional advantage, Siemens’ treasury is able to further support the company’s product and solutions business lines. With access to payment programmability, Nix explains that the development and scaling-up of sales operations can be achieved through, for example, the offer to clients of pay-per-use functionality.

Journey to programmability

“There is a need for a certain technical and process maturity to use programmable payments,” cautions Nix. The luxury of having a “strong and advanced internal global cash management system” means Siemens has been able to easily integrate programmability using APIs; there is no other way of making the required real-time connections.

Even with the appropriate technology stack, Nix states that the system has to be transparent and intuitive, barely registering with users that there is a different mechanism enabling automated 24/7 cash movements. As he notes: “We want all the benefits of the crypto world like programmability and 24x7, but without the disadvantages.”

Despite (or perhaps because of) the understandable apprehension of both J.P. Morgan’s and Siemens’ teams prior to the first transaction, this solution works. The first payment after initial tests was an internal transfer of €100m, with success giving Siemens the confidence to begin external programmed transactions.

“There have been a few lessons learnt on the journey,” admits Nix. “It’s obvious with hindsight, but executing an instantaneous transaction from Singapore to New York must be a back-dated deal, because at some point in New York it’s still yesterday!”

Future prospects

“Industry is realising that digital currencies have a future, and that commercial banks have a foundational role to play in the growth of tokenised deposits, and especially in establishing templates for their use,” says Mallela. “Real-world asset tokenisation requires digital currencies to settle transactions with atomicity. That’s why we see J.P. Morgan heading further in this direction, not just for treasury transactions and integrated business processes, but also for the integration of asset settlements to provide DvP.” 

However, Mallela believes that more discussion is now needed around the externalisation of bank accounts, so that they reside within many more corporate clients’ technology environments. “There’s a wider vision needed, too, of how we can make payments a much more integrated and embedded part of the corporate digital business model,” he adds.

With Siemens learning while it travels ever further on its programmable payments pathway, Nix says it is “opening up more use cases”. Building out the fundamentals has, of course, been a vital part of this journey, and while the pioneering nature of it is attracting much media attention, he is keen not to become absorbed in flights of fancy. “We’ve tried to explain its features to our businesses and they are starting to think about how their products can be integrated with payments. But it’s still a work very much in progress.”

Siemens has already issued a digital bond; the team is now considering the next one, not only with on-chain issuance but also the settlement on-chain. Another project under discussion is the idea of ‘composability’, says Nix. This describes how various applications can seamlessly communicate with each other so that, in combination, new structures are created.

Bringing FX transactions on-chain with programmable payments could see, for example Siemens’ USD account in New York ‘integrate’ with its EUR account in Frankfurt, so that transfers provide new benefits. Again, says Nix, it’s under development “but very exciting”.

There is much ground to cover still, but for Dengler, this is a source of fascination. “On the one hand, blockchain and DLT is a great technological leap forward because, for the first time, it is possible to safely convey data in an atomic way,” he comments. “And on the other hand, this new technology is being combined with the stable and highly regulated banking environment.”

By making the connection between these seemingly at-odds components, Dengler believes considerable value can be generated. “And with the bank’s creativity, this will develop and grow over time to bring the industry to the next level.”

Sign up for free to read the full article

Download this articles as a PDF
Article Last Updated: May 03, 2024

Related Content