Deliver2Pay: The Invoice Is Only the Beginning
“Virtually every commercial transaction has within itself an element of trust.”
Kenneth J. Arrow, Nobel laureate in economics (1921 to 2017)
PILLAR III – From Documents to Verifiable Trade Objects – Part 3 of 3:
By Stephan Wolf, Chair of the Board of Trustees at Verifiable.Trade Foundation
October 2026
The Cardano/Veridian & Certizen invoicing prototype: what it demonstrates for the future of digital trade
Somewhere in Hong Kong, a finance manager finishes an invoice and sends it to a customer in Switzerland. By the time the Swiss team starts their working day, it is waiting in their inbox. The numbers match the order, the logo is where it should be, and so someone approves it and the money moves.
Businesses repeat this small ritual millions of times a day, and most of the time it works. Look closely, though, and it rests on a surprising amount of faith. The recipient assumes the invoice really came from the supplier, that the person who sent it was allowed to, and that nothing was changed along the way. Anyone who has ever chased a disputed payment or caught a fake invoice knows how much risk hides inside that one small word: assume.
Deliver2Pay was built to find out whether that faith can be replaced with something better. The prototype, coordinated by the Verifiable.Trade Foundation together with Certizen in Hong Kong and Veridian in Switzerland, asks a simple question: Can two companies in different countries exchange business information directly, and both be certain it is genuine, without either of them having to join the same platform? The early answer is encouraging, and the reasons behind it say a lot about where trade could go next.
Why trade still feels so fragmented
Invoice, delivery, confirmation, payment. On paper it is a straight line, but in the digital world every step tends to cross a boundary of some kind: between companies, between software systems, between countries and their rules. The seller works in one accounting system and the buyer in another. The shipping company has its own tools, customs has its own portal, and the bank runs on infrastructure of its own.
The usual answer has been to bring everybody onto a shared network or platform. That works well inside the walls of each network, but the walls remain. A company that trades widely ends up juggling logins, interfaces and intermediaries, each of which vouches for its members in its own way. Trade has become very digital without becoming very connected. The challenge is therefore no longer how to digitize trade, but how to make processes that were digitised separately work together.
Trust that travels
The central idea behind Deliver2Pay is to change where trust comes from. On a typical platform, you trust the other party because the platform has checked them. Step outside the platform and that trust stays behind, much like a club membership card that means nothing beyond the club door.
Deliver2Pay starts with the company itself instead. In the prototype, organizational identity is established with the verifiable Legal Entity Identifier, or vLEI, the digital and verifiable form of the global identifier that many companies already hold. An employee of the Hong Kong seller acts with a vLEI credential that lets the recipient verify both the organization behind the invoice and the authority under which that person is acting. Think of it as digital evidence of two things at once: who the company is, and who may speak on its behalf.
The recipient can check who issued the information and whether that person was authorized to act for the company. They can also check where the information came from and how it links to earlier records, such as the invoice to which a delivery confirmation refers. This is its provenance. Digital signatures allow the recipient to detect whether the signed information has been changed since it was issued, protecting its content integrity.
The evidence needed for these checks accompanies the information, allowing the recipient’s own software to verify it. This does not guarantee that every business claim is true, but it establishes who made the claim, whether it has been altered and how it relates to the transaction. In the prototype, these checks rely on the vLEI trust framework. GLEIF operates this globally federated, trust-based governance model for the vLEI ecosystem, establishing common standards, policies, and accreditation requirements while Qualified vLEI Issuers (QVIs) issue and manage verifiable credentials for businesses and their representatives under GLEIF oversight. GLEIF itself operates under public-sector oversight through the Regulatory Oversight Committee (ROC), comprising representatives of public authorities worldwide, ensuring that the vLEI ecosystem benefits from independent oversight, global interoperability, and a trusted governance framework.
Ultimately, each recipient remains responsible for deciding whether to accept the information based on its own business rules. What becomes portable is the supporting evidence, eliminating the need for each platform to independently re-establish the company’s identity.
An invoice that computers can actually read
The second shift concerns the invoice itself. Much of what we call digital today still imitates paper. A conventional PDF invoice is designed first of all to reproduce the document people read, and unless structured data is embedded in it or sent alongside it, software has to extract and interpret its contents before anything can be processed reliably.
In Deliver2Pay the invoice travels as structured data: who sold what to whom, at what price, on which terms and when payment falls due. Because both the sender and the content integrity can be verified, the receiving system can process it straight away. It can also link the invoice to whatever happens next, such as the delivery confirmation that follows, so the whole transaction becomes one connected story rather than a pile of separate files.
What happened between Hong Kong and Switzerland
The prototype follows one ordinary deal from start to finish. Pearl Dragon Trading Limited, a trading company in Hong Kong, sells headsets, charging cables and power banks to AlpenTech Import AG in Switzerland. Both companies are invented for the demonstration, but the steps they go through are exactly those of a real export deal, and so are the banks standing behind them.
Four parties, one connected flow: trade documents move between the companies, and the importer’s confirmation sets the payment in motion between the banks.
Four parties take part: the exporter, the importer and each of their banks. The invoice and the delivery note travel between the two companies, and the importer’s signed confirmation of delivery becomes the verified event from which the payment instruction is created. Every step is taken by a named person acting for a named organization, so the recipient always knows both who acted and on whose behalf.
Hong Kong: issuing and signing
In Hong Kong, the invoice is created, signed by phone and issued as a verifiable credential.
On the seller’s side, Certizen’s CertLEI system does the work. A Pearl Dragon employee enters the invoice, scans a QR code with a phone to sign it, and the system issues it as a verifiable credential tied to the company’s official identity. The delivery note follows the same route, and both documents set off for Switzerland together.
Switzerland: receiving and confirming
In Switzerland, AlpenTech receives the documents in its Veridian wallet, checks them and signs off the delivery note.
In Switzerland, the documents arrive in AlpenTech’s Veridian wallet. An AlpenTech employee is notified, accepts the invoice and can open every detail to see who issued it and when. When the goods arrive, the same or another authorized employee signs off the delivery note with AlpenTech’s own vLEI credential.
That signed confirmation is the verified business event from which the payment instruction is generated. In this way the prototype connects the commercial side of the deal with the payment process. The actual settlement of the payment remains, as it should, within the banking system.
Underneath this simple experience sits a different way of establishing trust. The invoice and the delivery note are issued as verifiable credentials, and cryptographic proofs bind each of them to the organization that issued it and the person who signed it. The prototype builds on two Trust over IP (ToIP) standards for this: KERI for managing identities and ACDC for the credentials themselves. The practical effect is what matters: the recipient does not need to trust whichever software carried the information in order to know where it came from.
Email could have moved these files from one continent to another, of course. But ordinary email offers no common way to verify the organizational identity of the sender, their authority to act, the origin of the business data and its link to the events that follow. That combination is exactly what Deliver2Pay adds.
It is worth noting that the Certizen and Veridian technology stacks were developed completely independently. They exchange and verify the trade information without a shared platform or even shared source code. Their interoperability comes from implementing common specifications for a protocol exchanging identity and verifiable data, while each operates its own technology stack.
Common rules, not another platform
This is where Deliver2Pay points to the bigger project behind it: the International Secure Trade Transfer Protocol, or ISTTP. The name sounds technical, but the idea is familiar. The internet did not succeed because everyone agreed to use the same website. It succeeded because very different computers agreed on shared rules for talking to one another, which is also why an email sent from one provider arrives safely at any other.
ISTTP aims to do something similar for trade. It is not a new marketplace, it does not gather everyone’s transactions in a central database, and it does not need a blockchain or distributed ledger to record them. It is intended to provide common rules for securely exchanging verifiable trade information between systems that are run independently of one another. Shipping software stays shipping software and banks keep their banking systems, but they all gain a common way to trust what they receive.
Nor does ISTTP replace the standards that already describe invoices, transport documents and payment messages, such as UN/CEFACT, PEPPOL or ISO 20022. Those standards remain essential, because they define what the information means. ISTTP addresses the gap between them: how that information moves between organizations together with the evidence needed to trust it, including who issued it, under what authority and how it relates to earlier and later events.
Working with established national infrastructures
Many countries already exchange structured, digitally signed invoices at scale. Latin America pioneered electronic invoicing, with Chile launching its system in 2003, followed by Brazil and Mexico. The Inter American Development Bank reports supporting implementation in 17 countries and all Brazilian states. Brazil’s Nota Fiscal eletrônica, or NF-e, combines structured XML invoices with digital signatures under ICP-Brasil and authorization by the tax administration. These are established national infrastructures with their own standards, trust arrangements and governance. [1, 2]
ISTTP’s proposed role is to help evidence produced within such systems travel across jurisdictions and independently governed environments. A Brazilian invoice should retain its original signature and tax authorization, with the evidence needed for a foreign recipient to verify them under agreed acceptance rules. Simply putting an invoice into a verifiable container would not establish recognition of its issuer or legal effect abroad. Where infrastructure is still being built, common exchange rules could also help prevent new silos.
The intended architecture does not require a single shared transaction platform or common operator. It does require compatible implementations and access to supporting services, such as issuer credentials and status information. Existing national services may remain necessary to validate evidence from their systems. The production requirements for discovery, delivery and verification still need to be specified and tested.
Recognition across different public key infrastructures, or PKIs, also needs explicit trust rules. Participants would need to agree which authorities they accept, how national identifiers map to organizational identities, and how certificate status and signing authority are checked. Those rules could be governed bilaterally or through agreed frameworks while each jurisdiction retains its own PKI. This is a design direction, not a result established by Deliver2Pay. The prototype uses the vLEI trust framework; it does not demonstrate a bridge between national PKIs or eliminate their existing trust anchors.
A related approach in open finance
A related interoperability objective is emerging in open finance, where customers can authorize the sharing of financial information across providers. The Bank for International Settlements’ Project Aperta tested how existing domestic networks could connect across borders. Its use cases included sharing verified business profiles for account opening and exchanging structured information for trade finance and payments. Aperta preserves domestic consent and authentication arrangements while using a central hub for application programming interfaces, or APIs, to translate data between standards, alongside a shared trust framework. [3]
This provides a useful comparison for ISTTP. Both approaches seek to make information usable across independently operated environments. Aperta connects existing networks through a common interoperability layer. ISTTP is being designed for direct exchange between systems, with evidence of identity, provenance and content integrity accompanying the information. These are different architectural approaches to a related problem. Deliver2Pay has not demonstrated interoperability with Aperta; any future connection would require technical integration and agreement on trust and governance.
Beyond the invoice
Once trusted information can be linked from one step to the next, the possibilities grow quickly. A carrier could add verified proof of shipment to the chain. A company that finances invoices could check the evidence before paying out, instead of collecting the same documents all over again. Customs could receive the details it needs from information that already exists in the transaction, rather than having someone type it in once more.
None of this means everyone sees everything. Each participant should receive only what it is entitled to, and protecting commercial privacy is a core requirement rather than an afterthought. The point is that whoever does receive a piece of information can check it for themselves, without rebuilding the chain of trust from scratch every time.
What the prototype demonstrates
A prototype is a proof of concept, not a finished product, and it is worth being precise about where Deliver2Pay stands. It involves two companies and a handful of steps, while a real supply chain can involve dozens of companies, several jurisdictions and a thick layer of regulation.
What it demonstrates today is that the essential pieces fit together: A company’s identity can be verified independently, and so can the authority of the person acting for it. Business data can be signed and exchanged directly between partners, then verified by the recipient without relying on a central transaction intermediary. Separate business events can be linked into one trustworthy sequence, and none of it requires a central database.
What it has not yet demonstrated is just as important to name. The prototype does not show operation at production scale, interoperability across many independent implementations, complex trades with many parties, or acceptance by regulators. It has not tested integration with national invoicing infrastructures or recognition across different PKIs. Those questions require further implementation and agreement on governance, alongside the planned work on customs, invoice financing, transport documents and integration into the systems companies already use.
Connect once, connect everywhere
For decades, digitizing trade has meant connecting systems one by one. The result is a dense web of platforms, portals and interfaces, many of them excellent at what they do. Yet there are hundreds of millions of businesses in the world, using different software under different laws, and no single platform will ever hold them all.
Deliver2Pay offers a glimpse of a different path. Its significance does not lie in sending an invoice from Hong Kong to Switzerland, which has been possible for a long time. It lies in showing that two independent companies can exchange information directly and still know who sent it, whom that person represents, whether they were allowed to send it and whether anything changed on the way.
If that approach can be standardized and widely adopted, the goal is no longer to connect every company to the same platform. It is to give independently operated systems a common way to exchange information they can verify for themselves. Connect once. Connect everywhere.
Acknowledgements
We warmly thank Certizen Ltd., Veridian and the Cardano Foundation for their fantastic development work and generous support for the Deliver2Pay prototype. Their technical expertise, commitment and close collaboration brought this cross-border demonstration to life. From issuing and signing credentials to receiving and verifying trade information, their teams turned the underlying ideas into a working experience. We are deeply grateful for the energy and care they have invested in the project, and for helping us show what trusted digital trade can look like in practice.
Glossary
The following explanations cover the principal technical and business terms used in this article.
ACDC. Authentic Chained Data Containers. A format and protocol for cryptographically verifiable data that can be linked to other containers, preserving evidence of its origin and relationships.
API. Application programming interface. Defined rules that allow software systems to request information or services from one another.
Blockchain and distributed ledger. A distributed ledger maintains records across multiple participants. A blockchain is one type of distributed ledger that links records in blocks. Deliver2Pay does not require either to record its trade transactions.
CertLEI. The Certizen system used in the prototype to create trade information, support signing and issue verifiable credentials.
Cryptographic proof. Mathematical evidence used to check properties such as who signed data and whether it has changed. It does not by itself establish that the underlying business claim is true.
Digital signature. A cryptographic mechanism that allows a recipient to verify that data was signed using a particular key and has not been altered. Credentials provide the additional evidence linking the signer to an organization and role.
Digital wallet. Software for managing digital identities, keys and credentials, and for signing or verifying information. Here, wallet refers to identity software rather than a payment account.
ICP-Brasil. Brazil’s public key infrastructure, which governs the certification authorities and digital certificates used to establish trust in signatures within that framework.
Interoperability. The ability of independently operated systems to exchange information and use it consistently under agreed rules.
ISO 20022. An international standard for financial information that provides a common approach to defining data and messages, including payment messages.
ISTTP. International Secure Trade Transfer Protocol. The protocol being developed by the Verifiable.Trade Foundation for securely exchanging verifiable trade information between independently operated systems.
KERI. Key Event Receipt Infrastructure. A protocol for managing cryptographic identifiers and verifying the history of the keys that control them, including changes to those keys.
LEI. Legal Entity Identifier. A globally standardized identifier for a legal entity, linked to reference information about that entity. The identifier alone is not a digital signing credential.
NF-e. Nota Fiscal eletrônica. Brazil’s electronic fiscal invoice, issued as structured XML with a digital signature and authorization by the tax administration.
Open finance. Sharing financial information and services across providers with customer authorisation, under applicable consent, security and governance rules.
Payment instruction and settlement. A payment instruction requests a transfer of funds. Settlement completes the transfer under the applicable payment arrangements. Generating an instruction is distinct from settling a payment.
PDF. Portable Document Format. A file format for preserving the layout of documents. A PDF may also contain embedded structured data.
PEPPOL. Pan European Public Procurement Online. An interoperability framework and network for exchanging business information, widely used for electronic invoicing and procurement.
Peer to peer exchange. Exchange between independently operated participants without requiring a central transaction platform to control their transaction records. Software, communications and credential services may still support the exchange.
PKI. Public key infrastructure. The authorities, certificates, policies and services used to connect public keys to identified parties and verify certificate status.
Provenance. Evidence of where information originated, who issued it and how it relates to other information or events.
QR code. Quick Response code. A machine-readable code that a phone or other device can scan. In the prototype, scanning a QR code forms part of the signing workflow.
Structured data. Information organized into defined fields that software can interpret, such as invoice amounts, item quantities and payment terms.
ToIP. Trust over IP. A collaborative initiative developing specifications and governance frameworks for interoperable digital trust, including the KERI and ACDC specifications.
Trust anchor. An authority or cryptographic key that a verifier accepts as a starting point for establishing trust. Different frameworks can retain their own trust anchors.
UN/CEFACT. United Nations Centre for Trade Facilitation and Electronic Business. A United Nations body that develops recommendations and standards for trade facilitation and electronic business information.
Verifiable credential. Digitally issued information accompanied by cryptographic evidence that enables a recipient to verify its issuer and integrity. Acceptance also depends on the issuer, credential status and applicable business rules.
Veridian. The digital identity wallet used by the Swiss counterparty in the prototype to receive and verify credentials and sign the delivery confirmation.
vLEI. Verifiable Legal Entity Identifier. A system of cryptographically verifiable credentials linking organizational identity to the LEI and enabling verification of the roles of people acting for that organization. Transaction authority must be assessed against the relevant role and business rules.
XML. Extensible Markup Language. A format for structuring data using named elements, used by Brazil’s electronic fiscal invoices.
