The future of payments: programmable payments in the IoT sector

24.Sep 2021 Category: Thought Leadership
Fintech Germany Award

The German industry is increasingly being digitalised. The Internet of Things (IoT) sector in particular promises revolutionary, novel business models that can have a positive impact on the competitiveness of the German industry. Distributed ledger technology (DLT) will also play an important part in this. In order to realise the full potential of the digitalisation of the industry, the entire payment process must now also be optimised and adapted to IoT payments, so that payments in connection with these new business models can also be processed efficiently, automatically and in real time. Due to the limitations of the current SEPA payment system, the processing of payments via a DLT offers such a payment solution. This paper analyses the status quo for IoT payments and shows how the industry benefits from innovative payment options, such as a European Central Bank (ECB) digital euro or a trigger solution that connects a DLT to the conventional SEPA system. Specific use cases regarding goods logistics and asset as a service / pay per use are examined.

 

1. The megatrend IoT

The digital transformation of business processes

The digitalisation of economy and society is progressing at a rapid pace. In particular, the Internet of Things (IoT) promises revolutionary business models with which the European industry can position itself as a global market leader. Here, the term IoT refers to the increasing networking of machines and devices. These devices are equipped with a digital identity, so that they can communicate with each other and execute processes autonomously without human intervention. This trend will become more and more relevant in the future. The total number of IoT devices is expected to rise to 75 billion by 2025.# These include, for example, machines, robots, sensors or other digital objects. The megatrend IoT will change the industry in the coming decades. The focus is not only on optimising and networking production processes to increase efficiency, but also on a complete digital transformation that enables new, innovative business models.

The networked industry transformation

Networked machines and devices will interact with each other in the future and replace manual intervention with intelligent, automated processes. However, the full potential of these IoT devices in the industry can only be realised if the entire end-to-end process line – from the performance of the service to the provisioning to the payment processing – is considered. In this way, the services of an IoT device and the corresponding payment can be performed immediately via the same infrastructure, possibly based on a distributed ledger. However, human interactions, such as a payment execution, currently interrupt the process and lead to a system disruption as well as only limited efficiency gains. Typically, today’s complex value chains, such as an international trading business, are very paper-based and analogous. However, if you exhaust the full potential of networked IoT devices, including the payment execution, new business models will emerge. Already today, it is no longer necessary to buy, rent or lease certain products. Instead, only the actual use is charged, which is called pay per use (see section 4.2.).

Payments as an important element

When we look closely at the pay-per-use business models and sketches of future approaches, it is noticeable that the integration of payments is often a particular challenge. As such, a human interaction is currently required to trigger payment orders. With the connection of machines in networks, the requirements for the digitalisation of the payment infrastructure are increasing considerably. Distributed ledger technology (DLT) can be used to fully exploit the potential. With the help of DLT, process logistics can be automated by means of smart contracts. The aim must be to provide the industry with the possibility of a seamless, efficient, immediate and scalable payment execution.

Potential analysis of a networked industry

Against the background of these challenges, this paper examines which solutions the current European payments offer for the industry for the payment processing and which technologies are required to exhaust the complete potential of networked machines and devices. Chapter 2 begins by explaining how payments are processed nowadays. It also addresses the associated problems and inefficiencies of the current payment system. Chapter 3 describes various DLT-based payment solutions that can be used to realise the full potential of IoT through automated IoT-based payments. These include a bridge solution linking the current (SEPA) payment system to the DLT environment, tokenised scriptural and e-money, and a digital central bank currency. Chapter 4 outlines and discusses exemplary IoT use cases that can benefit significantly from DLT-based means of payment.

 

2. Payments today

2.1. Payments as means of transport of value and information

Cash-on-delivery transactions

There are two key elements to payments: a value is to be transferred and, simultaneously, an information is to be transported. These are the classic answers to the questions: who, to whom, how much and why? In the case of cash payments, the transfer of value is obvious. What we have in that case are the cash-on-delivery transactions. For this, especially in the business environment, the information required as invoice and receipt is just as physical, i.e. not digital, as the transferred value.

Digital payments

In addition, a digital alternative has long been established with so-called electronic payments. The necessary payment information is transferred digitally by exchanging defined formats, usually XML according to ISO 20022. The file transfer usually takes place according to the EBICS standard or, analogous to online banking, according to the FinTS standard. The check of the digital signature of the file transfer sender is followed by the actual value transfer through bookings between digitally managed accounts. The operators of these accounts are regulated financial institutions, which are linked by so-called clearing houses. Thus, a payment from the payer to the recipient represents a chain of bilateral file transfers and corresponding bookings.

2.2. SEPA payments

Participants of a payment process

Thanks to regulations and standardisation, in Europe – more specifically in the Single Euro Payments Area (SEPA) – payments are realised according to the process outlined in figure 1.

The main bilateral relations exist between the payer and their financial institution on the one hand and between the payment recipient and their financial institution on the other. For the transfer of the information, the payer’s financial institution searches for a route to the payment recipient’s financial institution, a so-called clearing route, i.e. the route that the payment will take from the payer’s financial institution to the payment recipient’s financial institution. The route is determined by the currency of the payment, the type of payment and the availability of the recipient bank. Euro payments in the SEPA can often be settled via clearing houses. For payments in other currencies, however, the so-called correspondent banking procedure is used. A clearing house replaces bilateral relations for all affiliated financial institutions and facilitates multilateral clearing.

Direct and indirect participants of the SEPA-Clearer

At this point, we want to focus on SEPA payments. The SEPA consists of a network of various national and pan-European clearing houses. We speak of indirect participants when a financial institution is connected to the clearing house via another financial institution, for example savings banks via their state banks. Otherwise, they are direct participants. Many financial institutions in Germany are linked to the clearing house of the Deutsche Bundesbank, the SEPA-Clearer, and can thus reach all other SEPA banks, if required, via the connection of the SEPA-Clearer with other clearing houses. How a financial institution is integrated into the SEPA network of direct and indirect participants at clearing houses depends on the type and size of the financial institution and is optimised in terms of settlement costs. Normally, a financial institution has only one access to the SEPA and therefore only access to one type of settlement, as the transfer of value is called. This settlement can be made on the bilateral clearing accounts of the financial institutions in scriptural money, for example via the SEPA-Clearer in the case of indirect participation or via TARGET2 equivalent payments in central bank money. The latter is the case in bilateral bank relations that are not settled via a clearing house. When using clearing houses, the settlement in central bank money via TARGET2 is a regulatory requirement.

2.3. The weaknesses of the SEPA payment system

Payments processing with a time delay

The regulation states that only one (TARGET) business day may elapse from the debit of the payer’s account before the value is credited to the payment recipient’s account. Thus, cases where a payment-on-delivery business is paid for in the classic SEPA system always include a risk. Either the payer pays before receiving the goods, thus making an advance payment and risking not receiving the goods, or the goods are delivered but not paid. For this, systems with payment guarantees, such as instant transfer or SEPA direct debit, have created extended, fee-based options that as a workaround minimise but do not eliminate the risk of a party not receiving the value.

Payments processing within seconds

These options subject to charge also include real-time credit transfers, which are available 24/7. In less than ten seconds not only the information (as with a payment guarantee) but also the value itself is transferred across Europe so that the payment recipient can use the received funds immediately. This makes a payment-on-delivery transaction possible in the same manner as a cash transaction, only in digital form. Unfortunately, not all financial institutions are yet accessible via this procedure, which is why the distribution is currently limited.

Lack of standards for automated payments processing

In the SEPA format the recipient as well as the sender is always addressed by IBAN. Universally easy-to-use means of communication such as e-mail or mobile phone numbers are currently not yet possible. For machine-to-machine payments there is still a need for suitable standards that would allow for continuous automated processing while also complying to all regulatory requirements. This is due i.a. to the fact that nowadays authorised persons have to authorise payments as part of a two-factor authentication. In the business environment, in particular, the four-eyes principle is often used.

Additional fields for payment information

The possibility of transmitting information has been improved with SEPA compared to previous national payment procedures. However, SEPA has not yet resolved the usual media breach between invoice data and intended use, which makes it difficult to automatically reconcile incoming payments with the payment recipient’s open invoices. Common is the use of the so-called unstructured remittance information, i.e. 140 characters free text, which allows the recognition of invoice number, customer number and similar information in the corresponding data field only via suitable algorithms when importing the account statement into the ERP system of the payment recipient. Structured remittance information, i.e. dedicated fields for necessary information, are not always possible here. These would be useful in the business environment, especially when combining several invoices in one payment, since the structured information of such data would be transferred in a standardised machine-readable manner. Such combinations are used to save costs such as transaction fees. In addition, the amount of these fees is one reason why payments in the cent range – so-called micropayments – are not economical. Even smaller units of value cannot be transferred with SEPA.

 

3. Next generation: possibilities of programmable payments

3.1. The two types of digital euro

Definition of a public digital euro

In order to increase process efficiencies and address the limitations of the SEPA system described in the previous chapter, the creation of an innovative European monetary system is essential. For example, the European Central Bank (ECB) could issue a central bank digital currency (CBDC), often referred to as the “public digital euro”. Since the ECB acts as the issuer, in contrast to the case of scriptural money transferred via SEPA, such a CBDC is central bank money, i.e. the CBDC holder holds a claim on the central bank. Currently, a CBDC is merely a theoretical concept: the ECB has not yet determined whether a CBDC will actually be issued. If it is, it will take at least five years for the digital money to be available to private and institutional end customers.

Private digital euro

In addition to the public digital euro, currently the e-money institutions, banks and, in some cases, non-regulated actors are also working on a so-called private digital euro (see figure 2) – often referred to as the DLT-based euro. A DLT-based euro allows programmable payments to be realised4 that are more relevant especially in the IoT sector. Specifically, payments can be defined that follow a certain logic and are processed automatically and, most notably, without human intervention.

The private digital euro and IoT payments

An example of an IoT use case is a pay-per-use process. For instance, if a machine is used for a certain period of time, it could automatically trigger a payment in the DLT-based euro using machine data such as information on maintenance or utilisation – without any human intervention. For this reason, programmable payments promise enormous automation potential. Nowadays there already are partially programmable payments, such as standing orders or scheduled credit transfers. However, so far the flexibility for this has been extremely limited. To realise the full potential of programmable payments, a DLT can be used. In a few lines of code even complex business logics can be implemented relatively easily by means of smart contracts. In addition, digital payment-on-delivery transactions are possible through the use of DLT. For example, a smart contract can be used to specify that the payment for goods is executed if the goods have also been dispatched. In this way, significant efficiency gains and lower counterparty risks can be realised. The first programmable euro-based payments are already available and therefore enable the implementation of micropayments and business models based on them.

3.2. The trigger solution for programmable payments

The trigger solution for IoT payments

A so-called trigger solution, also called a bridge solution, refers to a technological connection, in this case between the SEPA system and a DLT-based application. This trigger enables a payment to be triggered in conventional payment transactions by passing on the corresponding transaction information. The DLT system connects two infrastructures: the DLT system used for performance and data communication, and the conventional SEPA system used to process the payment. Figure 3 illustrates the trigger solution and shows the interaction between the two systems. While the DLT system plays a key role in the identity of the machine and the interaction with the owner, the SEPA system is required as soon as payment orders are triggered as a result of the interaction.
Optimal delivery-versus-payment (DvP) function cannot be implemented with trigger solution

The advantage of such a solution is that no special novel, tokenised, i.e. DLT-based, monetary units need to be created for use in the DLT environment. Such a solution is therefore relatively straightforward and can be implemented and used in the short term. A disadvantage here is, however, that no optimal DvP can be implemented for the realisation of payment-on-delivery transactions. The tokens created represent only a claim on the financial institution and are linked to a subsequent SEPA credit transfer. For this reason an asymmetry is created for a short period of time, as the financial institution first has to check the account balance and/or credit limits. After successful verification, a DLT-based token is created with the credit note, i.e. a promise of payment, which is then available to the payment recipient. When this token is redeemed, it is technically destroyed and simultaneously triggers a SEPA transaction, depending on the financial institution this might happen in real time. Thus, it is technically possible to map a DvP function that makes payment-on-delivery transactions possible. However, this function triggers the transfer of funds at a later date. Especially in DLT environments, this poses a particular challenge, as so-called atomic transaction settlements are necessary for the full transfer of ownership of the digital assets. In this context, the term describes the complete and irreversible transaction processing and transfer of the assets.

DLT as a common decentralised platform

DLT environments are especially necessary when machine-to-machine payments, IoT payments, automated payments and/or pay-per-use payments are to be realised. Due to the usually automatic execution of payments in the IoT environment based on machine and/or sensor data, the data integrity is an important success factor in the implementation. Accordingly, DLT is suitable for use as a single source of truth (SSOT), i.e. a technical, automatic notary function between all parties involved. In addition, identities are also assigned to the machines using the SSOT function. This is absolutely necessary in order to be able to trace transactions in an autonomous payment transaction. The SEPA system is currently unable to integrate this necessary SSOT function into the payment process. No automatic payments can be made without SSOT and without a unique assignment of the IoT devices by means of a machine identity. Although programmable payments of less complexity can be realised by means of standing orders or direct debit procedures, these instruments are increasingly reaching their limits for automated and non-discretionary (rule-based) use cases. The current forms of credit transfers are limited to 27 characters according to the Home Banking Computer Interface (HBCI) specification and can only trigger monthly transfers.

Complexity of settlement

The trigger solution enables classic payments to be programmable for the first time and works without system breaks thanks to the seamless integration of payments and sensor data. Due to the high degree of automation, the efficiency of currently often still manual processes can be increased. The programmability of the payment flow also allows settlement models according to different metrics and any complexity, for example regarding operating hours, kilometres or weight. This also makes data-driven business models fully comprehensive and automated.

Pioneers of the trigger solution

Some financial institutions in Europe are currently working on the realisation of payments via DLT networks. The trigger solutions outlined above can be used to map programmable payments to DLT and trigger and execute them via the existing payment systems. In this context, CashOnLedger is active in cooperation with Landesbank Baden-Württemberg (LBBW) in the scope of a development partnership in order to make the benefits of DLT available to companies.
Trigger solution as the first step

Since the trigger solution is an additional component for existing payments, apart from the possible programmability of payments, the same limits apply as for the current payment transactions. The transfer of small amounts is still not economically feasible and therefore not the use case of streaming money. During the consumption or use of content, this utilisation is to be charged in the form of very small amounts. Here it would only be possible to work with threshold values and automatically initiate credit transfers above a certain value. Furthermore, even with the trigger solution machines do not have any identity, which makes it extremely difficult to trigger a payment. Restrictions such as two-factor authentication as a regulatory hurdle still exist in this context. In practice, this means that a machine or IoT device cannot yet realise the settlement and debit the amount from the account. For this, the confirmation of the user is required as an intermediate step. In addition, only a euro token issued directly to DLT enables a real-time settlement of payments, as the currency would be natively integrated into the platform. With the trigger solution, the duration for a transaction execution is approximately the usual SEPA processing time of up to one day. However, if a euro token is issued directly via the DLT instead of the SEPA system without media disruption, the transaction execution and settlement take place in real time. In such a case, the liquidity would be immediately available to the payment recipient and third parties such as clearing houses would no longer be needed.

3.3. Alternatives to the trigger solution

Native DLT-based payment means

The limitations of the trigger solution described in the last paragraph can be addressed by the native DLT-based means of payment described below. Unlike with the trigger solution, it is thus possible to realise native DvP, micropayments, streaming money and the integration of machines.
Stablecoins and tokenised e-money

Stablecoins are DLT-based tokens that replicate a stable asset. For example, the euro can be used as a token in a DLT system. The DLT system plays the role of the carrier platform, the token plays the role of a unit of value. The main difference to the trigger solution is that the payment is not made via the SEPA system but via the DLT. In this way, the system break for the payment processing can be avoided. So far, there are first projects for euro-based stablecoins, but US dollar-based stablecoins are far superior in size and scope of application. Regulation of euro stablecoins is – as of today – non-existent but is to be created by the planned EU regulation “Markets in Crypto-assets” (MiCA). In this case, the e-money policy would apply to such tokens, so that stablecoins can be referred to as tokenised e-money. Currently, unregulated euro stablecoins have a significant counterparty risk. This is one of the reasons why stablecoins are hardly used so far.

Tokenised scriptural money

In addition to euro stablecoins, there is also the possibility that financial institutions could issue scriptural money in DLT systems. The main difference to the previously discussed euro stablecoins or tokenised e-money is that stablecoins under the e-money regime would require 100 % coverage, for example through scriptural money. If, for example, e-money tokens worth 100 euros were issued, exactly 100 euros would have to be deposited as a cover. In contrast, full coverage is not required for tokenised scriptural money. This means that financial institutions can continue to create money – only in a DLT. A digital euro provided in this way could also be used for programmable applications. The implementation of such a solution is currently being studied by numerous financial institutions in a conceptual manner but would be extremely complex due to the standardisation measures necessary to ensure interbank interoperability. Moreover, there is currently no effort on a European level to implement such a solution in the short to medium term. However, even tokenised e-money is associated with a significant disadvantage, which has a negative impact on its distribution. Due to scriptural money being used as the cover for e-money, tokenised e-money is not multi-bank capable and thus presents a different risk depending on the issuer because of its limited fungibility. Consequently, by issuing e-money you are tied to one institution, which means that both the sender and the recipient of the payment must be customers of the same institution.

Digital central bank currencies

In addition to private sector players such as financial and e-money institutions, the central bank could also spend DLT-based money. In the case of the euro area this would be the public digital euro. At present, the ECB has not yet made a decision as to whether it will actually issue a digital euro. The question also remains whether a digital euro based on DLT would be implemented, which currently seems unlikely. However, only a DLT-based digital euro would break the limitations regarding micropayments, streaming money and machine integration into the payment process. As a result of these uncertainties, tokenised e-money and tokenised scriptural money appear to be the most promising solutions for IoT payments in the short to medium term, with the short-term realisation of tokenised e-money currently being much more likely due to the MiCA regulation that will take effect in as little as one to two years.

 

4. Business models of the future based on programmable payments

Use cases for IoT payments

With programmable payment solutions, various use cases for IoT payments are conceivable. This chapter explains two specific use cases: an automated payment process based on a delivery of goods and an asset-as-a-service or pay-per-use scenario based on the financing of machines.

4.1. Use case 1: automated payment processes in goods logistics

Lack of synchronisation of payment and goods flow

In goods logistics, cash flows are often neither synchronised nor automated in terms of time compared to goods flows. The transaction processing usually takes several days. In addition, goods logistics today still require a lot of documents: delivery notes, freight documents, customs documents and invoices are exchanged between the parties.

Efficient payment processes throughout the entire supply chain

With IoT it is possible for intelligent and interconnected sensors, robots and machines to execute certain processes independently and without human intervention. Machines can be equipped with wallets, which are charged with a certain budget of digital euros. In conjunction with smart contracts implemented via a DLT, machines could automatically trigger payments as soon as certain conditions are met, such as the arrival of the goods, their completeness and the absence of defects. All parties may pre-define these terms in a DLT protocol. With self-paying machines the following use case of a goods delivery, as shown in figure 4, would be feasible:

1. The buyer has ordered goods from the supplier. An intelligent machine from the supplier triggers the dispatch of goods. It places a kind of token, such as a QR code, on the goods. This token can contain various data as well as payment information. The token may be registered by the machine in a DLT platform. All parties involved in the goods logistics are thus informed about the current status of the order.
2. The goods are sent in several intermediate steps. At the respective intermediate steps and during the receipt of the goods, intelligent machines check the goods via the attached token. In the case of a shipment from abroad, the first stop could be at the customs or the port authority. At customs, a machine checks the goods and automatically determines the customs duties due based on the weight, size and origin. The customs office machine sends the collected data to a supplier’s machine for the purpose of determining customs duties. The supplier’s machine will then automatically pay the customs duties after the information has been received.
3. As soon as the goods have arrived at the recipient, the goods are registered by a machine via the token. A scanner checks the goods for completeness and defects. If discrepancies or defects are found, the supplier will be informed accordingly, accompanied, if necessary, by a photo or a scan of the damage. Certain discounts could be automatically included, or a new shipment of the goods could be triggered. If, on the other hand, all checks are positive, the recipient’s machine triggers a payment via its wallet. The machines receive the respective confirmations of the executed transactions in their wallets. The buyer and the supplier could also receive these confirmations, for example via an app in the form of structured data records for accounting or in the form of an invoice for downloading.
In the long term a DLT-based euro is needed

All solutions described in chapter 3 can be used to implement this use case. In the short term a trigger solution with the combination of the SEPA payment system and the DLT system could be implemented. The trigger solution, however, is only a technical bridge solution since conventional payments are supplemented by DLT-based applications. The current limits of SEPA payments, such as the release by a person as part of a two-factor authentication, remain in place. This does not yet achieve complete automation of the processes, which will be necessary in the future. The DLT-based euro would therefore be the preferred medium- to long-term solution.

4.2. Use case 2: asset as a service / pay per use

CAPEX to OPEX as growth driver

Another use case is an asset as a service using the example of machine financing. Pay per use is the billing modality in which costs for machines are calculated after effective use. Until now, the forms of financing for the purchase of a machine are relatively rigid and do not offer the necessary financial flexibility for medium-sized companies and customers. Classic (operating) leasing binds companies to a machine over a fixed term, regardless of its utilisation. A purchase via financing usually binds the customer’s capital over several years or decades.

Asset-as-a-service models

Asset-as-a-service models as an alternative are a further development of today’s operating leasing. The customer now pays primarily after the use of a machine, but not according to its possession. The rental periods are also shortened and can be limited to the desired project periods. As a result, long-term obligations are eliminated and the company that uses the machine retains greater financial flexibility. However, the manufacturer now bears the risk of the utilisation and profitability of the machines, since ownership of them does not pass to the customer. The manufacturer must now trust that his end customer will generate the necessary utilisation of the machine.

New collaborations

In order to offset this risk, the manufacturer can now work in partnership with financial services providers in new ways as opposed to the prior classic lending, and thus increase the debt capital. A potential solution could be to sell the machines to the financial service provider, who in turn rents them out. The maintenance is performed by the manufacturer since the highest possible residual value can be achieved in the event of a subsequent sale on the secondary market. Given the ongoing low interest rate policy and potential, this option is attractive to asset managers and financial institutions.
The combination of financial service and technology

To exploit the full potential of renting out the asset, it is additionally necessary to consider the different use types and the utilisation rates of the vehicles and machines for the billing instead of a flat rate. For agricultural machinery it is possible to distinguish between light- and heavy-duty use of the vehicles – for example, depending on the area of application and the utilisation. The striking differences between heavy forest use and lighter transport journeys should be mentioned here. Such usage scenarios not only generate a higher profit, but also help in calculating the residual value on the basis of the resulting wear profiles. The necessary steps and technical interfaces are depicted in figure 5. In the first step, the vehicles or machines must provide corresponding telemetry data, which they then transfer to a cloud. The utilisation is then calculated based on this machine data. This also allows conclusions to be drawn regarding the product life cycle. Finally, the third step relates to the effective settlement of the accounts by means of a payment.

Programmable payments

This advanced level of complexity necessitates the use of programmable payments. New business models require not only programmable payment flows but also the necessary technical infrastructure for their full use by the industry. Such payments can only be triggered if a corresponding accounting logic is predefined.
Asset as a service: new leasing success model 2.0
The success of asset-as-a-service models therefore depends to a large extent on the cooperation between financial services providers and the industry. Without the seamless integration of these two worlds, it will be impossible to implement new digital business models based on IoT data. Today’s payment systems have certain limitations and requirements that can only be solved by manual processes. For example, the two-factor authentication prevents a machine from paying independently. The owner or user must release a transaction. Even though this security feature is justified, new approaches are necessary if machine payments are to be implemented in a scalable manner. Furthermore, scaling through automation requires overcoming the system discontinuities that exist in today’s payment sector.

 

5. Conclusion

The ECB’s digital euro is coming

It is likely that the ECB will issue the public digital euro, but not before 2026. It is also unclear in what exact form the ECB will provide the digital euro. Nevertheless, the digital euro on a DLT basis will already exist beforehand, and this will be realised by private sector financial institutions. Starting in 2021, the first financial institutions in Germany will be offering their customers solutions with which the digital euro on DLT basis can be transferred by means of smart contracts.
Euro-based smart contracts

The benefits of euro-based smart contracts are clearly visible for the automation of business processes, significant increase of process throughput times, simplified payment processes, and the enabling of IoT payments from machines or other devices. This will now be possible from 2021, when solutions are created in various ways to enable smart contracts to execute euro-based payments.

Trigger solution and e-money token

In the short term, the trigger solution will enable programmable payments. DLT networks are connected to the existing IBAN account infrastructure. The result: the euro is then accessible to smart contracts, even if the traditional IBAN infrastructure actually remains. Another alternative is the tokenised e-money. In this case, a euro token is issued – based on the e-money regulations – which can then be transferred directly on a DLT network.

2021 is the starting signal for the application of the digital euro

2021 will be the starting signal for companies from various sectors – for example production, logistics and medical technology – to be able to handle new business models and automated business processes. Important industrial sectors in Germany and Europe, such as industry 4.0, supply chain management and future mobility, will benefit significantly from the DLT-based digital euro, because B2B models and cross-company B2B processes are possible that previously seemed impossible or were inefficient. The digital DLT-based euro will contribute to the digital transformation of these areas and enable new business models. What’s more, the digital transformation in these areas is even accelerated by the digital euro, and in some cases only made possible. It is therefore important for companies in the above-mentioned areas to look into the digital euro and the resulting possibilities such as programmable payments.

Authors

Maximilian Forster
Co-founder and CBDO, CashOnLedger

Jonas Groß
Chairman,
Digital Euro Association

Anja Kristina Kamping
Senior Consultant
Payments, PPI AG

Serkan Katilmis
Co-founder and CEO, CashOnLedger

Dr. Mario Reichel
Managing Consultant
Payments, PPI AG

Prof Dr Philipp Sandner
Head of Frankfurt School Blockchain Center

Philipp Schröder
Managing Consultant
Payments, PPI AG

ASK FOR A DEMO

Why should you reach out?

In an initial online meeting, we usually present CashOnLedger in depth and explain how Asset-as-a-Service models can enable your business.

Showing you already implemented use-cases, will help you shaping your idea. Based on your input, we are implementing a demo with your requirements for the next touchpoint and can take it from there.