SIGN AIR: A Case Study on Technological Innovation, Data Sharing and Smart Contracts for Multimodal Travel

Abstract / Summary 

SIGN-AIR is a European innovation project that develops a B2B platform enabling transport service providers (TSPs) - airlines, airports and railway operators - to collaborate on multimodal travel through standardised Data Sharing Agreements (DSAs) and Smart Contracts. The platform addresses the core obstacles to seamless multimodal travel: fragmented heterogeneous data formats, the absence of interoperable contractual frameworks, and the lack of automated disruption management. It does so through a set of integrated modules: a Catalogue of Catalogues providing a metadata layer for dataset discovery; TransiTool for data format conversion; a Synchronisation Module for timetable alignment between TSPs; a Disruption Management Module for connection feasibility assessment; and a blockchain-based contract execution environment supporting the full lifecycle of DSAs and Smart Contracts from negotiation through to post-settlement. 

The contractual architecture consists of a template-based DSA governing data sharing terms and conditions, a Single Ticket Smart Contract (STSC) allocating responsibilities between a Contracting TSP and Operating TSPs for multimodal journeys sold under a single contract, and a Disruption Management Smart Contract (DMSC) automating the detection, assessment and handling of disruptions in near real time. These contracts are negotiated electronically in natural language, executed via software code, and anchored on a blockchain-based module that records tamper-resistant proofs of events, decisions and settlements. The platform supports end-to-end automation of key workflows including revenue sharing, passenger notification, re-routing, reimbursement, care and assistance, and post-disruption financial settlement between TSPs. 

The legal and regulatory framework applicable to SIGN-AIR is complex and still evolving: it encompasses the General Data Protection Regulation (GDPR), the Data Act, the Data Governance Act, the eIDAS Regulation, NIS2, mode-specific passenger rights regimes, and the pending EU proposal on multimodal passenger rights. A few regulatory questions - including GDPR consent management across multiple TSPs, the NIS2 obligations of the platform operator, and the potential applicability of B2C consumer law if a Travel Companion would be integrated - remain open or are subject to anticipated legislative changes under the Digital Omnibus Package. 

Table of Contents 

1. Introduction
2. Challenges of multimodal travel 
3. The objectives of SIGN-AIR 
4. The Catalogue of Catalogues
5. Data conversion via TransiTool
6. The Synchronisation Module
7. The contractual process
8. Nature and validity of electronic contracts
   1. Introduction
   2. Overview of the EU regulatory framework on the validity of electronic contracts 
   3. Validity of electronic contracts and electronic signatures 
9. Smart contracts 11
   1.  Introduction 
   2. Smart contracts and blockchain 
   3. Automation, AI and emerging uses of blockchain contracting 
   4. Smart contract implementation in the SIGN-AIR platform
10. Legal and regulatory dimension
    1.  Passenger rights
    2. The Data Act
    3. The Data Governance Act - is SIGN-AIR a "data intermediation service"?
    4. GDPR - consent management by several TSPs 
    5. Applicable law and jurisdiction
    6. NIS2 and cybersecurity - asymmetric obligations
    7. Platform-to-Business Regulation and Consumer Rights
11. Data Sharing Agreements 
12. Smart Contracts in SIGN-AIR
    1. Single Ticket Smart Contract
    2. Use cases of Smart Contract execution 
    3. Disruption Management Smart Contract 
    4. Smart Contract execution and post-settlement
13. Post-settlement
14. Overall execution model
15. Conclusion

1. Introduction 

SIGN-AIR (full title: Implemented SynergIes, data sharing contracts and Goals between transport modes and AIR transportation) is a European innovation project funded by the SESAR 3 Joint Undertaking under the Horizon Europe programme (grant agreement no. 101114845) . The project runs from June 2023 to May 2026 and is coordinated by the Universitat Politècnica de Catalunya (UPC) in Barcelona. It builds on the SYN-AIR project (2020–2022), which provided the conceptual foundation for the current project. 

In April 2026, the SIGN-AIR technology was validated in a controlled test environment. The components of the solution are integrated and operational using simulated data, but as of May 2026 the platform had not yet been deployed in a real-world operational environment. 

The central objective of the project is to develop a "one-stop-shop" platform for multimodal collaboration between transport service providers (TSPs) - such as airports, airlines and railway operators - with the aim of enabling seamless door-to-door travel for passengers. SIGN-AIR is a B2B platform designed for TSPs, delivering a significant part of the back-office infrastructure needed to facilitate multimodal travel. The platform does not interact directly with travellers; instead, it is envisaged that TSPs will build their own interfaces with passengers' mobile devices - so-called Travel Companions - through which that interaction is created. 

Multimodal travel means that a passenger combines several different travel modes for a single journey to a given destination - for example, taking a local train to a station where a high-speed rail service is available, boarding that train to an airport, and then flying to the final destination. The defining characteristic is that the passenger can make this journey under a single arrangement, with the various legs combined into one coherent travel experience . 

In practice, however, such journeys are structured in very different ways. In many cases, passengers purchase separate tickets for each individual leg, bearing the full risk themselves if a connection is missed. In other cases, intermediaries - such as online travel agencies or MaaS platforms - bundle separate tickets into a multimodal product and sell them in a single commercial transaction, though without necessarily providing unified passenger protection across the entire journey (combined contract) . More rarely, carriers themselves offer the journey under a single contract of carriage, which typically provides the strongest level of passenger protection and the clearest allocation of liability between the parties involved. 

In practice, genuinely multimodal travel requires, among other things, that: 

• the passenger plans his or her door-to-door journey as a single whole, rather than booking each mode separately and independently; 
• transfers between the different modes are properly coordinated, so that successive legs of the journey can realistically be made and the planned chain is not broken; 
• information, ticketing and customer service are aligned across all modes involved - ideally through a single search, booking and payment flow, or at the very least through transparent combinations that give the passenger a clear overview; 
• multiple providers (rail, bus/tram/metro, aviation, MaaS and shared mobility operators, taxi services, etc.) cooperate both operationally and contractually to ensure that the journey runs smoothly for the passenger from end to end; 
• efficient solutions are available when a disruption occurs on one leg of the journey, causing delays or making it impossible to reach subsequent connections, so that the passenger is not left to resolve the situation alone across multiple separate contracts and providers. 

Several examples of such cooperation already exist in practice. Air France and SNCF have for many years offered combined train-and-flight tickets under the "Train + Air" brand. The passenger books in a single step a ticket that combines a TGV or other SNCF train service with an Air France flight within a single PNR , and benefits from a missed connection guarantee in the event of a delay - meaning a seat on the next available flight or train at no additional cost. Lufthansa and Deutsche Bahn collaborate since long through "Lufthansa Express Rail": a combined ticket under which ICE high-speed trains operate feeder services to Frankfurt Airport under a Lufthansa flight number. The passenger books train and flight in a single transaction, with a transfer guarantee included. More recently, a DB City-Ticket has been added, extending the same ticket to cover local public transport to and from the ICE station at either end of the journey. Austrian Airlines and ÖBB offer "AIRail": Railjet connections are integrated into Austrian Airlines' global hub structure. Passengers receive a single ticket, earn Miles & More points on the rail segment, benefit from guaranteed connections, and in some cases enjoy baggage handling arrangements that bridge the boundary between the train and flight portions of their journey. 

Single tickets are furthermore implemented in city and metropolitan areas (for instance, T-Mobilitat in Barcelona, ATHENA in Athens, MOBIB in Brussels, and VIVA VIAGEM in Lisbon). 

2. Challenges of multimodal travel 

Notwithstanding successful examples, in practice multimodal travel remains far from seamless : 

• At the booking stage: information and ticketing are fragmented across multiple channels. Passengers must search, book and pay separately with different providers; a coherent overview of options, prices, rights and risks is frequently absent; 

• Poor coordination of timetables: transfer times are not aligned across train, bus, aviation and other modes. When connecting times are too tight, even a minor delay on one leg can result in a missed connection that derails the entire travel plan; 

• Unclear responsibility in the event of disruption: when connections are missed or services cancelled, it is often far from clear which party is responsible for assisting or compensating the passenger, particularly where tickets have been purchased from different providers under separate contracts; 

• Limited data exchange between operators: smooth data exchange between the various operators is essential for multimodal travel to function properly. In practice, however, TSPs use different data formats and standards, are reluctant to share operational data with one another because of competition issues, and lack the tools to make data available in a secure and standardised way. Some experts believe that multimodal travel will only work if TSPs will be forced to share their data with digital platforms and intermediaries. 

Although multimodal mobility ranks high on the European policy agenda, data exchange between operators remains limited in practice and is often purely bilateral: carriers share data selectively with individual MaaS platforms or cities, but are reluctant to grant broader access for fear of competitive disadvantage or loss of control over their fares and customer relationships. To break this deadlock, the EU has in recent years been building a regulatory framework that incrementally mandates and structures data sharing. The updated ITS Directive and the Multimodal Travel Information Services (MMTIS) Regulation require Member States and transport operators to make static and increasingly dynamic travel and traffic data available through National Access Points (NAPs) , in standardised or fully compatible formats, so that multimodal travel information services can operate seamlessly across borders. In parallel, the European Commission is developing a specific regulatory framework for multimodal mobility platforms under the heading of 'Multimodal Digital Mobility Services' (MDMS), which is currently still under discussion. Member States, industry associations and the Commission have already agreed on a number of principles regarding data sharing, non-discrimination and possible Fair, Reasonable and Non-discriminatory (FRAND) conditions, but no finalized legislative text has yet been adopted . In essence, MDMS focuses primarily on intermediaries - MaaS providers and other digital ticketing platforms - and seeks to determine under what conditions they should be granted access to TSPs' data and ticketing interfaces, and which forms of self-preferencing or exclusivity by TSPs are problematic in a healthy, open mobility market. 

The MDMS initiative is closely linked to the broader ambition of a common European Mobility Data Space (EMDS) , one of the sectoral data spaces envisaged under the EU's European Strategy for Data and the Sustainable and Smart Mobility Strategy . Where MDMS focuses on the regulatory and commercial conditions under which digital mobility platforms and operators must share data and ticketing access, the EMDS provides the underlying technical and governance infrastructure: a federated, interlinked framework of existing and future transport data ecosystems that enables data to be discovered, accessed and shared in a trusted and standardised way across borders, without creating a single centralised database. The EMDS is not yet fully operational: a preparatory phase was completed in September 2023, and a three-year deployment action (deployEMDS), is currently underway, focusing on concrete data-sharing use cases in urban mobility and traffic management across nine European cities and regions. In practical terms, the EMDS and MDMS are therefore complementary: the EMDS builds the pipes and governance rules for data sharing, while MDMS determines who must use those pipes, on what terms, and with what passenger protection obligations attached. A legal framework is therefore being developed that will push TSPs not merely through moral persuasion but through binding legal obligations towards more structured data exchange. 

• Complex and fragmented legal framework: each transport segment (aviation, rail, bus, maritime, MaaS) currently has its own regulations and contractual practices. The existing European legal framework for passenger protection (passenger rights) applies only within a specific mode - such as air or rail travel (see infra, section 10.1) - while cross-modal passenger rights and B2B data arrangements have only been partially developed. 

The current underdevelopment of multimodal travel is undesirable from a policy perspective. The European Commission has placed a clear focus on multimodal travel, directly in line with the Commission's own agenda: the Sustainable and Smart Mobility Strategy explicitly pursues "connected and automated multimodal mobility", in which passengers can easily purchase tickets for journeys combining multiple modes, and where systems connect seamlessly through data sharing. The Commission seeks to safeguard the interests of travellers (and in particular their passenger rights), while also aiming to provide greater legal certainty for carriers. Through the Passenger Mobility Package and the proposed regulation on passenger rights in multimodal travel, the Commission intends to enshrine that vision in law, including through mandatory improved pre-contractual and in-journey information, clear rules for missed connections, and special attention to persons with disabilities or reduced mobility. For travellers, this could translate into a series of concrete benefits: greater freedom of choice between combinations of flights, trains, buses and shared mobility services; one consistent set of rights across the entire journey; and smoother door-to-door travel with less uncertainty about connections, assistance and compensation in the event of disruption. 

For carriers, the current state of multimodal travel represents not only an operational burden but also a missed market opportunity: without reliable data exchange and clear B2B arrangements, it is difficult to offer multimodal products at scale - such as single ticketing, guaranteed connections, joint assistance for passengers with reduced mobility (PRM assistance), and integrated disruption management - let alone to organise fair revenue and risk sharing around them. The result is that each operator optimises its own segment of the journey, while no one takes ownership of the end-to-end chain - leading to fragmented investment, higher transaction costs, and a suboptimal passenger experience. SIGN-AIR departs from this dual challenge - the lack of legal certainty and the absence of interoperable data infrastructure - to build a platform where TSPs can collaborate safely and profitably on multimodal services, on the basis of standard contracts, standardised datasets and automated monitoring. 

3. The objectives of SIGN-AIR 

SIGN-AIR intends to tackle several major obstacles to multimodal cooperation simultaneously. Data sharing between heterogeneous TSPs is facilitated through the use of standardised Data Sharing Agreement templates, in which many clauses are pre defined while still allowing TSPs to negotiate the necessary adjustments via an electronic negotiation process. Data exchange, including real time data, is organised around a central “Catalogue of Catalogues” that references the datasets of participating TSPs, enabling them to see which data are available when negotiating transactions for a given service offering or route. The challenge of divergent data formats is addressed through format conversion carried out via the platform, which enables effective technical communication between systems (see section 5). 

On the basis of this standardised data, train, bus and flight timetables can be better synchronised: the platform supports timetable synchronisation between two TSPs with a view to ensuring acceptable transfer times between modes and thereby reducing the risk of missed connections (see section 6). In addition, the platform includes a module for the automated replanning of routes when a leg has been missed, allowing intermodal re routing to be triggered in near real time (see section 12.3). 

4. The Catalogue of Catalogues 

Rather than becoming a data hub itself, SIGN-AIR builds a “Catalogue of Catalogues”: a metadata layer in which carriers describe which datasets they hold, in what format, under which conditions, and through which technical channels (API, file, NAP link, etc.) they can be accessed. This catalogue is aligned with existing European vocabularies such as DCAT-AP and napDCAT-AP , so that data already published via NAPs can easily be found and combined with additional datasets that are (not yet) listed on a NAP. For TSPs, this means they do not need to upload raw data to SIGN-AIR, but only register their basic information, while the platform then uses that information to propose possible collaborations for multimodal contracts and to test and monitor the appropriate data connections.

For TSPs, this approach offers several clear advantages: they retain control over their data, since it essentially stays at the source and is only made available through existing channels (for example their own API or a NAP publication). At the same time, they avoid duplicate effort: the same dataset that they already have to publish via a NAP because of MMTIS obligations can, through the Catalogue of Catalogues, also be used in multimodal contracts on SIGN-AIR, without separate upload flows or additional formats. Finally, it lowers the threshold for entering into new collaborations: by first sharing only the metadata and then, in a subsequent Discovery phase and via a Data Sharing Agreement, arranging the concrete access and usage rights, TSPs can make much more targeted decisions about who they want to share what with, and under which conditions. 

5. Data conversion via TransiTool 

When a TSP registers with SIGN-AIR, it specifies which data it wishes to share with other TSPs. This may include various types of information, but the most important are flight data and timetables. These data are then described in a Catalogue, which is integrated into the overall Catalogue of Catalogues. One of the main practical hurdles is that TSPs maintain their datasets in very different formats. SIGN-AIR addresses this through TransiTool , an existing platform developed by the Greek company Aethon that has been integrated into SIGN-AIR and has been extended to handle and convert multiple data formats. TransiTool translates a TSP’s data into a standardised format chosen for this project, taking into account the standardisation requirements of the ITS and MMTIS rules mentioned above. This conversion enables TSPs to “speak the same language” for planning, monitoring and multimodal ticketing. Standardisation is also crucial for interfacing with NAPs, where operators publish data in accordance with MMTIS Regulation (see section 2). The key standards are IATA SSIM (aviation: flight schedules), GTFS (public transport, originally developed by Google and used worldwide) and NeTEx/SIRI (European standards for static and real-time public transport data, mandatory for NAPs). 

6. The Synchronisation Module 

The Multimodal Synchronisation Module is another external component integrated into the SIGN-AIR platform. It calculates connectivity between transport services and generates optimized combined travel itineraries under a single ticket, by assessing timetables and transfer times across different alternative routes. The module evaluates which combinations of flights, trains and other modes are realistically feasible given the available transfer times and proposes combined itineraries accordingly. These outputs are essential both for planning itineraries and for assessing whether a given delay is likely to result in a missed connection at the next transfer point, and for proposing alternative routes for re-routing in case of a missed connection. 

The module builds on the study work of researchers at the University of Belgrade (Faculty of Transport and Traffic Engineering), who developed an Air–Rail Connectivity Index that allows comparison between different airports and rail links on aspects such as the number of available connections, transfer time, frequency, reliability and total travel time. Each connection is given a score that reflects how attractive or unattractive it is for the passenger. Carriers that make their data (air schedules and rail timetables) available to SIGN-AIR can agree with each other to synchronize their timetables for certain routes and to use the scores of the module to adjust poorly scoring services and to select the best routes for inclusion in smart contracts (see section 9.4). The same data are also crucial in case of disruption: when a delay occurs, SIGN-AIR’s disruption management module (see section 12.3) can use these indicators to assess whether there is a realistic chance of making the next leg, and trigger appropriate decisions. When the disruption module has to propose alternative routes after a missed connection, it will suggest the best alternatives, again leveraging these connectivity scores. 

7. The contractual process 

The contractual process for Data Sharing Agreements (DSAs) and Smart Contracts unfolds in five stages: 

1. Onboarding – A TSP registers on the SIGN AIR platform. The duly authorised representative electronically signs a User Agreement (in which the TSP designates the individuals who are allowed to use the platform) and the Terms and Conditions. The Terms and Conditions include, among other things, an allocation of liability between the TSP and the SIGN AIR operator. Both the User Agreement and the Terms and Conditions are concluded by means of an electronic signature. Once these framework documents have been executed, the TSP completes its entry in the Catalogue of Catalogues by specifying the datasets it is willing to make available, the APIs through which those datasets can be accessed, and the formats in which they are provided. 
2.  Discovery – In the Discovery phase, a TSP identifies potential partners with whom it wishes to issue single multimodal tickets for specific connections, or with whom it seeks to synchronise timetables in order to optimise certain connections. SIGN AIR’s Matching Mechanism scans the Catalogue of Catalogues and proposes pairs of TSPs that could enter into DSAs and Smart Contracts, based on overlapping data types and aligned multimodal objectives. 
3. Negotiation – The two TSPs negotiate the specific clauses of their DSA and Smart Contract. They start from contract templates proposed by the SIGN AIR platform. These templates contain a mix of mandatory clauses (from which the TSPs may not deviate) and default clauses suggested by the platform that can be modified or replaced. In some instances, the TSPs can choose between predefined options via drop down menus, while in others they may insert additional bespoke clauses where appropriate. The initiating TSP adapts the template and sends its first draft to the counterpart, entirely within the platform environment. The receiving TSP can accept the proposed wording or suggest revisions and return an amended draft. The parties can thus exchange successive draft versions of the DSA and Smart Contract within the platform until agreement is reached. Once consensus on the contractual text has been achieved, the operational part of the Smart Contract is translated into executable code. 
4. Settlement – Both parties execute the DSA and the Smart Contract by means of an electronic signature in accordance with the eIDAS Regulation . At this stage, the contractual “connectors” are tested: the platform verifies whether the data flows are structurally correct and whether the agreed triggers can in fact be monitored in an automated way. 

5. Post Settlement – Once in force, the platform continuously monitors the triggers defined in the Smart Contract in real time. When a trigger condition is met, the corresponding action is recorded and communicated to the parties, and - where relevant - integrated with Travel Companion applications for travellers, so that travellers can effectively benefit from, and see, the rights and advantages arising from the multimodal contract. 

   The SIGN-AIR project includes the creation of a glossary of terms and definitions used in the travel sector and in regulatory documents, which has been useful to apply consistent language in the contracting process and the contract templates. 

8. Nature and validity of electronic contracts 

8.1 Introduction 

The development of digital technologies has generated a variety of labels to the technological change in contracting such as electronic contracts, digital contracts, telematic contracts. These labels represent a heterogenous set of contract models which have certain common features: use of electronic means in one or more stages of the contractual process. These stages would typically include communication of offer, expression of acceptance, transmission of contractual terms, or the performance of obligations. In this sense, the digital environment changes the medium of contracting more than the essential legal structure of contract formation. 

Electronic contracts, therefore, can be best understood as contracts concluded through digital means. Their legal assessment continues to depend on traditional contract law requirements such as offer, acceptance, intention, capacity, and compliance with any mandatory formalities. At the same time, the digital context introduced new issues relating to information asymmetry, identity verification, proof, and the automation of decision-making. 

Practically, electronic contracting may occur in Business-2-Business (B2B), Business-2-Customer (B2C) or Customer-2-Customer (C2C) relations. Procedurally electronic contracts may be concluded through traditional click-wrap model or acceptance through electronic means such as email or a communication mechanism provided on a platform, ideally combined with a digital signature mechanism. 

8.2 Overview of the EU regulatory framework on the validity of electronic contracts 

Within the EU, the regulation of electronic contracts developed primarily in response to the rise of e-commerce and the broader objective of building the internal market. EU law sought not only to encourage cross-border digital trade, but also to ensure that consumers would enjoy a high level of protection in online commercial relationships, thereby combining market integration with regulatory safeguards. 

Contract law in Europe remains largely sectoral in nature and continues to rest primarily on national contract laws. Within this framework, Articles 9 to 11 of the E-Commerce Directive address the conclusion of contracts by electronic means and establishes the general requirement that Member States must ensure their legal system permit contracts to be concluded electronically. Because the internet makes it relatively easy for parties to conceal their identity and may complicate transparency in the contractual process, the EU legislator introduced a number of information obligations for providers of information society services. These obligations must be fulfilled in a clear, comprehensible, and unambiguous manner, irrespective of whether the recipient is acting for professional or non-professional purposes. 

Across all Member States, a common requirement for the validity of an offer is that it must contain the essential requirements prescribed by national law. More generally, all Member States recognise the principle of “freedom of form”, meaning that parties are in principle free to choose the form of their contract unless (exceptionally) legislation requires a specific form. 

As a general rule, a contract is considered formed when the offeror receives the acceptance of the offer. This rule is expressly reflected in laws of most Member States. In the context of smart contracts, however, identifying the act that constitutes the offer may depend on the circumstances. Where a smart contract merely implements a prior written agreement the offer may have been made off-chain, whether orally or in writing. By contrast, where the smart contract itself embodies the agreement, the posting of the smart contract on distributed ledger technology (DLT) may itself amount to the offer. Likewise, acceptance under national law may occur either through performance or through the authorisation of a transaction, for example by signature or a private cryptography key. In addition, some Member States have adopted specific rules for electronic contracts. Even so, the general principle of “freedom of form” continues to apply unless the law requires a particular form. Such formal requirements typically arise where the contract, or its subject matter, must be registered with a public authority, or where the contract must be executed by notarial deed (typically, for instance, in the domain of real estate).

8.3 Validity of electronic contracts and electronic signatures 

As contracts increasingly came to be concluded by electronic means concerns emerged regarding their legal validity. These concerns were particularly significant where the laws of Member States required contracts to be in writing, with non-compliance leading to nullity or the possibility of annulment. At EU level, legislative efforts were undertaken both to remove barriers to electronic contracting and to facilitate its use. For instance, the E-Commerce Directive requires Member States to ensure that their legal systems permit contracts to be concluded electronically, and that the legal requirements applicable to the contractual process do not create obstacles to the use of electronic contracts or deprive such contracts of legal validity and effectiveness merely because they were concluded by electronic means. This is set out in Article 9 of the Directive, otherwise known as the “principle of equivalence” of contracts made on paper and electronic contracts. 

EU law also developed mechanisms to place electronic signatures on a similar legal footing to handwritten signatures, through its digital equivalent governed by the eIDAS Regulation. Article 25(1) of eIDAS Regulation states that an electronic signature cannot be denied legal effect just because it is in electronic form. Article 25(2) states that a qualified electronic signature (QES) has the same legal effect as a handwritten signature. Article 25(3) states that a QES based on a qualified certificate issued in one Member State shall be recognised as a QES in all Member States. Whereas in the context of smart contracts registered on a DLT system, Regulation (EU) 2024/1183 amended the eIDAS Regulation to introduce provisions on electronic ledgers within the eIDAS framework, inter alia, setting out requirements for qualified electronic ledgers.

9. Smart contracts 

9.1 Introduction 

Although smart contracts are often discussed alongside electronic contracts, the two notions should not be conflated. An electronic contract is a legal agreement concluded through electronic means. A smart contract, by contrast, concerns the automation of contractual performance through software, often on a blockchain or other DLT. In other words, electronic contracts concern the mode of conclusion; smart contracts concern coded execution. The execution of a contract by the software code implies that it can be performed without human intervention or with minimal human intervention. 

Smart contracts on blockchain may be described as software programs that are stored and executed in a decentralized manner across multiple nodes, that automatically perform trigger - action (“if this, then that”) commands, and that operate on a public ledger whose contents cannot easily be altered. This automated and decentralized execution distinguishes them from earlier forms of electronic contracting, which still depend largely on centralized infrastructure and human administration. 

The term smart contract itself is, however, ambiguous. A distinction can be drawn between smart contract code and smart legal contracts. Smart contract code refers to software stored, verified, and executed on a blockchain. Smart legal contract refers to the use of that code to articulate, verify, or enforce an agreement between parties. This distinction is crucial, because not every smart contract code is itself a legal contract; sometimes it is merely a technical tool within a broader commercial or legal arrangement.

A smart contract does not operate in isolation; its execution depends on predefined variables that are populated with data originating outside the blockchain environment. These external inputs - such as real-time transport data, delay notifications, or availability of alternative routes - are typically supplied via APIs and introduced on-chain through so-called “oracles,” which act as trusted intermediaries between off-chain data sources and the smart contract. In addition, certain decision points in the contract may depend on input from the passenger, for example when choosing between re-routing, continuation, or cancellation in case of disruption of the journey. While such user input is not always formally classified as an oracle, it similarly represents off-chain information that conditions the contract’s execution. As a result, both automated data feeds and human interventions can influence the contract’s behavior.

9.2 Smart contracts and blockchain 

The concept of smart contracts was formulated before blockchain technology existed, but later developments in DLT made it technically feasible to implement the early vision of smart contracts in a decentralized manner. 

Generally speaking, blockchains or DLT infrastructures can be deployed on standalone or in combination with other technologies such as IoT, cloud services, big data. Blockchain can be considered as one type of DLT which can be operated on either public or private interfaces. In a private DLT system, the participating entities can agree on the rules and procedures through which a transaction can be validated and operated on the basis of smart contracts. 

From a technological standpoint, smart contracts are software programs developed in specific programming or standards and deployed on blockchain platforms. Their execution is collective and decentralized: network nodes validate the transaction invoking the smart contract and execute the code under the protocol rules of the underlying blockchain. Because execution is deterministic and based on on-chain data, each node should reach the same result when processing the same input and blockchain state. This ensures consistency across the network. 

Typically, a user triggers the smart contract by sending a transaction often called a call, to a particular function in the code. If the transaction complies with the blockchain’s consensus and validation rules, the smart contract executes the specified logic. The result may be the approval of a payment, the transfer of a tokenized asset, the update of a ledger entry and so on. 

Smart contracts therefore inherit core blockchain properties: immutability, traceability, transparency, and decentralized validation and storage of transactions in cryptographically linked blocks, creating a chronological and non-editable record. Because of the immutability of the recorded transactions, blockchain technology provides a particularly strong evidentiary value for the existence, content, and timing of those transactions. 

9.3 Automation, AI and emerging uses of blockchain contracting 

Advancements in automation of contracting supported by artificial intelligence and DLT are fast emerging across various sectors. The recently adopted UNCITRAL Model Law on Automated Contracting was designed to provide a legal framework to enable the use of automation in international contracts, including through the deployment of AI techniques in smart contacts as well as in DLT transactions. The Model Law is the first legislative text to result from exploratory work conducted by UNCITRAL on legal issues related to the digital economy and digital trade, with work on data contracts and distributed ledger technology ongoing . 

9.4 Smart contract implementation in the SIGN-AIR platform 

Within the SIGN-AIR platform, the Smart Contract is negotiated and concluded electronically on the platform in natural language and confirmed by digital signature. That arrangement is then linked by reference to software code capable of automatically executing case-by-case applications of the contract (see the examples in section 12.4). In this sense, the code serves as a means of implementation and execution rather than as a substitute for the legal agreement itself. The contracts are registered on the blockchain thereby providing a transparent and verifiable audit trail of all contract actions, including signatures and amendments. 

10. Legal and regulatory dimension 

The operation of the SIGN-AIR platform and the contract templates must comply with the GDPR , the EU Data Act , the Data Governance Act , the existing mode specific passenger rights acquis, and the expected future framework on multimodal passenger rights, which the EU has not yet adopted. 

10.1 Passenger rights 

In regulatory terms, the landscape for passenger protection is very much in flux. Taken broadly, passenger rights revolve around a core bundle of entitlements: the right to clear and timely information; the right to re routing to the final destination in the event of a missed connection; the right to reimbursement and return to the point of departure where continuing a heavily delayed or disrupted journey has become pointless; the right to financial compensation in defined circumstances; the right to care and assistance (meals and hotel accommodation) when a journey is severely disrupted, and the right to assistance for passengers with reduced mobility (PRM). 

Currently, passenger protection in the EU is governed mainly by mode specific regimes for air, rail, bus/coach and waterborne transport, each of which applies to a single leg or contract of carriage rather than to a multimodal chain as such. As a result, travellers generally enjoy only limited protection when they miss a connection between different modes within a multimodal journey, unless the entire itinerary has been sold under one single contract of carriage (for example a through ticket in rail transport or the future “single multimodal contract” envisaged by the Commission’s proposal on passenger rights in a multimodal context). 

For air travel, passengers have been protected since 2005 by Regulation (EC) No 261/2004 , complemented by updated interpretative guidelines adopted in 2024 . In cases of denied boarding, cancellation or long delay, passengers are entitled to information, care (meals, hotel accommodation where necessary, and means of communication), a choice between reimbursement and re routing, and, in many situations, a lump sum compensation of between EUR 250 and 600 depending on the flight distance and the delay at arrival. Through a combination of Court of Justice case law and the Commission’s guidance, it is now well established that delays of around three hours or more at the final destination, as well as missed connections within a single booking that cause such delays, can fall within the scope of the compensation regime. 

In parallel, the Council has, since 2025, revived the long stalled process of revising Regulation 261/2004, with politically sensitive discussions on, among other things, the thresholds for compensation, the treatment of “no show” clauses , enhanced protection for persons with disabilities or reduced mobility, and stronger enforcement mechanisms; however, the ultimate outcome of these negotiations remains uncertain at this stage. 

For rail passengers, Regulation (EC) No 1371/2007 has been replaced by the recast Rail Passenger Rights Regulation (EU) 2021/782 , which grants rights to information, in the event of delay a choice between reimbursement and continuation of the journey, care, and partial reimbursement of the ticket price (typically 25–50% in cases of substantial delay), albeit with exceptions in situations of force majeure and for certain ticket types. The recast rules also introduce an obligation to offer through tickets in a number of situations and provide that full protection only applies where the journey is sold under a single contract; where passengers travel on separate or combined tickets, their rights are more limited and fragmented.

In both the air and rail regimes, the rights of persons with disabilities and reduced mobility (PRM), as well as the corresponding assistance duties, are laid down in separate instruments, and complaints must first be addressed to the carrier, with possible escalation to national enforcement bodies and alternative dispute resolution schemes. 

The SIGN-AIR project focuses primarily on the combination of air and (high-speed) rail transport, and partly also on eVTOLs . In addition to air and rail, there are specific EU regimes for bus and coach transport (Regulation (EU) No 181/2011 ) and for sea and inland waterway transport (Regulation (EU) No 1177/2010 ), which provide broadly comparable core rights relating to information, care in the event of delays, and special protection for persons with disabilities or reduced mobility. These regimes operate, as in the case of air and rail, mainly on a mode-by-mode basis and per individual contract of carriage, and therefore offer protection in multimodal chains only for that segment of the journey which falls under the respective transport contract. 

The Commission explicitly recognises that this regulatory patchwork is insufficient for multimodal journeys and has therefore, as part of the Passenger Mobility Package, published a Multimodal Proposal .That proposal introduces uniform definitions for three types of multimodal tickets, each associated with a different level of protection for passengers and distinct obligations for carriers and intermediaries:

• Single multimodal contract (single ticket, category A): a single continuous contract covering the entire multimodal journey, based on prior arrangements between the participating TSPs. In the event of a missed connection within such a contract, the passenger is entitled to reimbursement or re routing for the whole journey, as well as care (meals, accommodation where necessary) under a regime broadly comparable to the mode specific rules. 
• Combined multimodal ticket (category B): separate contracts of carriage that are nevertheless bundled, on the initiative of a carrier or intermediary, into a single transaction. In this case, the proposal grants a more limited set of rights, but imposes a clear liability on the seller: in principle, where a missed connection occurs, the seller must reimburse the full ticket price and pay an additional 75% in compensation (subject to how the offer is presented to the passenger). 

• Separate multimodal tickets (category C): standalone tickets, combined by the passenger himself (or sold in a way that involves separate payments), without any contractual link between the segments. In such cases, passenger rights largely remain confined to the existing mode specific regimes for each individual leg, with virtually no protection for the multimodal chain as a whole in the event of missed connections. 

The nature of the ticket determines the obligations of TSPs and the rights of passengers in a multimodal context: 

• For a single multimodal contract, chain liability shifts to the “contracting carrier”: in the event of a delay or cancellation on an early leg, that carrier must ensure that the passenger is rebooked or reimbursed for the entire multimodal journey, and that appropriate care is provided while the passenger is waiting. 

• For a combined multimodal ticket, primary responsibility lies with the carrier or ticket vendor who assembled the bundle: where tickets are presented as a quasi integrated product but without underlying inter carrier arrangements, that seller must, in the event of a missed connection, refund the full price and pay an additional 75% in compensation. 

• For separate tickets, responsibility in principle rests with each individual carrier for its own service; in this category, the multimodal regulation focuses mainly on minimum information and transparency obligations, rather than on a continuous compensation regime spanning the whole journey. 

The proposal makes it clear that the way in which the ticket is presented to the passenger is crucial. Sellers (including intermediaries) must, before purchase, clearly indicate whether the passenger is buying a single multimodal contract, a combined multimodal ticket or merely separate tickets, and must explain the level of protection attached to each type. If they fail to do so - for example by marketing separate or combined tickets as if they were a single integrated ticket offering full protection - they risk additional liability, including an obligation to reimburse the fare and to pay further compensation. 

The proposal also focuses on information obligations: 

• Carriers and intermediaries must, before purchase, provide clear information on: the type of multimodal ticket being sold (single/combined/separate); the corresponding rights in the event of delay, cancellation and missed connections; and any limitations to protection (for example, the absence of chain liability where separate tickets are used). 
• During the journey, passengers must be informed in good time and in an accessible format about delays, the risk of missed connections and available alternatives, with particular attention to the needs of persons with disabilities or reduced mobility. 

At this stage, the proposal is still going through the legislative process in the Council and the European Parliament. 

In developing the template for the Single Ticket Smart Contract (STSC), the SIGN-AIR project was confronted with the uncertainty surrounding future passenger rights rules, which will need to be properly reflected and guaranteed in the contract. Building on the core principle of the Commission proposal, the project opted for a structure in which a single “Contracting TSP” assumes responsibility vis à vis the passenger for the entire multimodal journey. This Contracting TSP bears both financial responsibility (fines, reimbursement obligations) and operational responsibility (the duty to organise re routing or return, to provide meals and accommodation, etc.). In their internal relationship, the TSPs can then agree a recourse mechanism under which the Contracting TSP is indemnified by the operating TSP responsible for the leg during which the disruption occurred, while the Disruption Management Contract agreed between the TSPs can spell out in detail which TSP must in practice execute the re routing, return, meals, accommodation or other assistance. Where an air carrier acts as Contracting TSP but the problem arises on a rail leg, it may in practice be more efficient for the concrete assistance measures to be carried out by the rail operator. 

10.2 The Data Act 

Article 36 of the Data Act contains the first official definition of a “smart contract” in EU law and lays down a number of essential requirements: robustness and access control, safe termination and interruption of automatic execution, data archiving and continuity, and consistency with the underlying data sharing agreement. An organisation that deploys smart contracts for others in the context of data sharing must, in principle, demonstrate compliance with these requirements through a conformity assessment and issue an EU declaration of conformity. The Data Act envisages that the European Commission will develop harmonised standards to support this process, but such standards do not yet exist. The SIGN AIR operator must therefore carry out a self assessment in the absence of formally defined standards, which creates legal uncertainty. At the same time, Article 36 Data Act is expected to be deleted in its entirety under the proposed Digital Omnibus Act . 

Article 13 of the Data Act provides that contract terms unilaterally imposed by one party in the context of data sharing may be regarded as “unfair” and declared null and void. This directly affects the templating mechanism of SIGN AIR: the templates must be sufficiently balanced so that none of their clauses can be successfully challenged as an unfair term. This requirement was taken into consideration when the templates were drafted. 

10.3 The Data Governance Act - is SIGN-AIR a "data intermediation service"? 

The Data Governance Act (DGA) imposes significant obligations on organisations classified as “data intermediation service providers” (DISPs), including notification requirements, operational restrictions and supervision by national authorities. Under the DGA, data intermediation services must be provided “through a legal person” that is structurally separated from the organisation’s other activities (Article 12), and DISP status is currently mandatory once the legal definition is met. In practice, this means a separate legal entity or, at a minimum, a strictly segregated business unit with its own governance, accounting, IT systems and contracts; data and metadata from the intermediation activity may only be used to improve that intermediation service itself. For organisations that build data marketplaces or matching platforms alongside other data driven activities, this results in additional costs (a new entity, separate infrastructure) and complex internal separation mechanisms (such as Chinese walls, separate pricing). 

Although the definition of a DISP in the DGA is not entirely clear, SIGN AIR should not be regarded as a DISP within the meaning of Article 10 DGA, because the platform does not establish commercial data sharing relationships between an indeterminate number of data providers and data users. The TSPs do not operate a business model based on paid data sharing, and SIGN AIR therefore does not function as an intermediary in such commercial relationships. Instead, SIGN AIR offers a broader set of services to TSPs, such as enabling timetable synchronisation and the issuance of single tickets. 

In the proposal for the Digital Omnibus Act (see above), it is also envisaged that DISP status will no longer be mandatory but will become an optional regime that a data intermediary can choose to apply for. In future, it will function as a voluntary label that may be commercially attractive because it provides assurances regarding the intermediary’s neutrality. The strict DISP requirements will not apply where an organisation chooses not to make use of this optional status. 

10.4 GDPR - consent management by several TSPs 

When a passenger books a multimodal journey and personal data are exchanged between multiple TSPs in that context (for instance, where an airline transfers passenger data to a rail operator for PRM assistance or for disruption-related re-routing), each TSP must have its own legal basis for personal data processing. Where the passenger’s consent is that legal basis, it must be specific, informed and unambiguous for each individual processing operation (articles 6 and 7 GDPR). 

The difficulty is that each TSP operates under its own privacy policy and its own terms and conditions. A passenger who purchases a ticket from an airline does not thereby automatically consent to the processing of their data by a rail operator. A system such as SIGN-AIR must therefore develop a mechanism through which consent is managed in a cascaded or bundled manner, but this is both technically and legally complex, and the GDPR leaves little room for generic or blanket consent. In practice, a workable solution may be for the TSP to obtain consent from the passenger directly through the Travel Companion app, and for subsequent processing by another TSP to rely on a token that identifies the passenger without transferring personal data directly. Whether this approach proves always viable in practice remains to be seen in a live production environment.

A further complication is that certain mobility data which do not, at first sight, qualify as personal data - such as real-time traffic data or travel patterns - may nonetheless constitute personal data in certain circumstances, given that travellers can become identifiable through their unique and consistent travel patterns. The boundary between anonymised data and personal data is therefore not a fixed one. The Digital Omnibus Package published by the European Commission in November 2025 proposes amendments to the GDPR that would narrow the definition of personal data. If those amendments enter into force, part of the current consent-related complexity would fall away. 

10.5 Applicable law and jurisdiction 

SIGN-AIR allows TSPs to include a choice of applicable law (in accordance with the Rome I Regulation ) and a choice of competent court or arbitration mechanism (in accordance with the Brussels I bis Regulation ) in their contracts. SIGN-AIR has deliberately refrained from imposing a single governing law or dispute resolution forum. While this offers flexibility, it may create some difficulty in negotiations: in the event of a dispute involving an Italian airport, a Belgian ticketing service and a French rail operator, which law would apply and which court or tribunal would have jurisdiction? These are matters that the TSPs themselves must negotiate and agree upon. 

10.6 NIS2 and cybersecurity - asymmetric obligations 

The NIS2 Directive imposes stringent cybersecurity obligations on “cloud computing service providers”, a category that includes the SIGN AIR platform operator. The NIS2 Directive will apply to the SIGN-AIR operator if it meets the relevant size thresholds. In general, the Directive applies to medium-sized enterprises - defined as entities with at least 50 employees or an annual turnover or balance sheet total exceeding EUR 10 million - and to large enterprises, defined as entities with at least 250 employees or an annual turnover exceeding EUR 50 million. Entities falling below these thresholds are in principle excluded from the scope of the Directive. 

However, at the same time, some TSPs (air carriers, airports, railway operators) are themselves NIS2 entities, which, as part of their supply chain security duties, must assess the security posture of their own suppliers, including SIGN AIR. This means that SIGN AIR must not only comply with NIS2 itself (depending on the thresholds), but also accommodate the audit and assurance needs of its TSP customers. The platform provider must therefore take “appropriate and proportionate technical, operational and organisational measures” to manage risks to network and information systems and to minimise the impact of incidents on service recipients. In practice, this requires implementing a formal cybersecurity risk management framework in line with NIS2 and the implementing regulation for cloud providers , and notifying significant incidents to the competent national authority in accordance with the timelines and thresholds laid down in NIS2. 

The aviation specific information security regulations (EU 2023/203 and EU 2022/1645 ) add another layer on top: where a smart contract enables data exchanges that affect aviation safety, security incidents must also be reported to aviation authorities. This creates asymmetric obligations, depending on which types of TSPs are party to a given contract. 

10.7 Platform-to-Business Regulation and Consumer Rights 

The SIGN-AIR platform is a B2B platform and does not directly interact with passengers or their Travel Companion apps. If SIGN-AIR were ever to integrate a Travel Companion through which consumers could purchase tickets directly, thereby adding a B2C layer, the Consumer Rights Directive, the Unfair Contract Terms Directive and the Platform-to-Business Regulation may become applicable. At present, the platform operates purely on a B2B basis, but its architecture already anticipates integration with Travel Companions - and it is at that interface that the regulatory perimeter becomes harder to delineate. 

The Platform-to-Business Regulation (Regulation (EU) 2019/1150 ) is of particular relevance in this regard. The Regulation imposes transparency and fairness obligations on providers of online intermediation services that connect business users with consumers. Its core requirements include an obligation to set out, in the provider's terms and conditions, the main parameters determining the ranking of search results and the relative importance of those parameters, as well as obligations regarding fair contractual terms, internal complaint handling, and access to out-of-court dispute resolution. 

In its current B2B configuration, SIGN-AIR does not straightforwardly qualify as an online intermediation service within the meaning of the Regulation, as it has no direct relationship with consumers. However, once a Travel Companion is integrated through which passengers can search for and purchase multimodal tickets, the picture changes. At that point, SIGN-AIR — or the entity operating the Travel Companion — would in all likelihood qualify as an online intermediation service, triggering the obligation to be transparent about how alternative routes and connections are ranked and displayed. This is not a trivial matter: where ranking algorithms favour certain TSPs over others, whether on commercial or technical grounds, passengers may be steered towards particular options without being aware of the underlying logic. This concern is reinforced by the CRS Code of Conduct (Regulation (EC) No 80/2009 ), which already requires non-discriminatory display of air and rail services in computerised reservation systems. 

11. Data Sharing Agreements 

The SIGN-AIR platform provides a template for Data Sharing Agreements (DSAs) under which TSPs can share data with one another. The TSP making data available is designated as the Data Provider TSP, while the TSP making use of that data is designated as the Data Consumer TSP. TSPs may take on both roles simultaneously in relation to each other, but in that case two separate DSAs are required. Each DSA specifies the objective of the data sharing arrangement, which corresponds to one of the multimodal transport goals supported by the platform: timetable synchronisation, single ticketing, or disruption management. In the case of single ticketing and disruption management, the operational modalities of the data processing are further governed by a Smart Contract, whereas the terms of the data sharing itself remain regulated by the DSA. The DSA describes the datasets to be shared, including their data categories (personal data, confidential information, and information protected by intellectual property rights), format, volume, static or dynamic nature, and method of distribution. 

The Data Provider TSP warrants that it holds all rights and authorisations necessary to make the data available to the Data Consumer TSP. Public transport schedules are preferably exchanged in GTFS or NeTEx format. The data sharing is in principle free of charge, although the parties may agree on a fee for the use of the data. The Data Consumer TSP is granted a non-exclusive right to use the data for the agreed Objective. That right expressly includes the use of automated processing techniques, including artificial intelligence and machine learning. The parties may, however, agree on specific restrictions regarding the use of the data. Redistribution of data to third parties is in principle prohibited, unless the DSA explicitly provides otherwise. “Derived Material” falls in principle outside the scope of the data restrictions and belongs to the party that generates it, unless the DSA stipulates otherwise. The boundary between data and Derived Material is, however, carefully delineated: processed material that can serve as a substitute for the original dataset, or from which the Data Provider TSP can be identified, continues to be governed by the restrictions applicable to the data itself. 

The parties may further agree on specific security requirements and confidentiality obligations, as well as audit rights to monitor compliance with the agreed terms. With regard to personal data, the default position is that no personal data relating to travellers are shared through the DSA itself. Where a TSP requires such data in order to execute a Smart Contract action, that data is collected directly from the traveller via a Travel Companion App using a token. Where personal data are nonetheless shared, both parties are considered to be independent data controllers within the meaning of the GDPR, unless they have concluded a separate Data Processing Agreement. The DSA incorporates a number of principles derived from the statutory requirements of the GDPR. Particular attention is required where personal data (or anonymised personal data) are to be transmitted to third party end users, in which case the conditions governing such transmission must be explicitly set out in the DSA. 

The DSA also protects any intellectual property rights that may exist in the data, which are not transferred unless the parties explicitly agree otherwise. Liability is limited to direct damages; consequential damages and loss of profits are excluded, except in cases of intent or gross negligence. The SIGN-AIR operator is expressly not a party to the DSAs and accepts no liability for the accuracy or availability of the shared data. 

TSPs negotiate the terms of the DSA using the template as a starting point. Draft versions are exchanged between the parties through the SIGN-AIR platform. Once agreement is reached, consent is evidenced by means of a digital signature. The executed contract is then stored on the blockchain. 

12. Smart Contracts in SIGN-AIR 

12.1 Single Ticket Smart Contract 

The Single Ticket Smart Contract (STSC) based on the SIGN-AIR template is negotiated and agreed on the SIGN-AIR platform as a contract drafted in English natural language. The template includes mandatory clauses, optional clauses and negotiable clauses, and includes dropdown lists and alternative clauses to facilitate the drafting. Once signed with a digital signature, it will be executed via an annex that contains the software code of the STSC. The contract defines key terms for multimodal transport such as Contracting TSP, Operating TSP, Single Ticket etc., based on the SIGN-AIR project’s glossary of terms. One TSP will act as the Contracting TSP that concludes the contract of carriage with a passenger covering the multimodal journey as a whole, while the other TSP acts as the Operating TSP for its own segment. Following the philosophy of the Commission’s 2023 proposal regarding passenger rights in a multimodal environment , the Contracting TSP remains liable towards the passenger for breach of contract, compensation, costs and damages and operational assistance (meals and accommodation). However the Contracting TSP and the Operating TSP may divide the financial and operational responsibilities between them and create a right of recourse.

The legal part of this smart contract is a comprehensive contract between two TSPs (an airline and a high-speed railway operator in SIGN-AIR’s use case) governing the issuance of a single ticket and its modalities. 

Some of the key terms are: 

• Covered Routes and the relevant hubs (airports with a railway station) where the passenger will switch from one leg to the following leg; 
• Validity of the single ticket (e.g. the use of the train is allowed on the day of the flight and possibly the day before and the day after);
• Indication of the TSP that will act as the Contracting TSP; • Pricing of the ticket; 
• Revenue-sharing agreement between the TSPs (with optional suggestions provided by the template); 
• Unavoidable extraordinary circumstances; 
• Luggage handling (optional); 
• Fast lane services (optional); 
• Cancellation by the passenger; 
• Cancellation by an Operating TSP; 
• Delay and disruption handling (basic principles if the TSPs do not conclude a specific Disruption Management Contract via the SIGN-AIR platform); 
• Financial liability between the TSPs. 

As it is a smart contract, the agreement states that certain obligations may be executed automatically through software code deployed on the SIGN-AIR platform while preserving the essential legal safeguard that the written terms, understandable in English natural language, prevail over the software code in the event of any discrepancies. As the execution of the smart contract depends on data fed into the contract, the Smart Contract is always based on a DSA agreed between the parties. 

After a successful negotiation, the Smart Contract is signed with a digital signature and stored on the blockchain. 

12.2 Use cases of Smart Contract execution 

When two TSPs sign a STSC, the issuance of actual tickets to passengers (via their Travel Companion or otherwise) will be recorded on the SIGN-AIR platform and will be stored on the blockchain as evidence. The name of an individual passenger is not disclosed to the SIGN-AIR platform but will be represented by a token. The SIGN-AIR platform will indirectly interact with the Travel Companion via the TSP who communicates to the Travel Companion of its passengers. For SIGN-AIR it is important to know which “tokenized” passengers, and how many, are impacted by a certain disruption event that occurs in one leg of the multimodal journey. In case of disruption, SIGN-AIR will calculate the feasibility of a continued travel and/or re-routing options based on that information. The disruption management process is discussed hereafter. In section 12.4 a number of use cases are described. 

12.3 Disruption Management Smart Contract 

The Disruption Management Smart Contract (DMSC) is a smart contract template for two TSPs, typically an airline and a (high speed) railway operator, participating in the SIGN-AIR platform. The DMSC is linked to the STSC. Its purpose is to define how the parties coordinate operationally and financially when a disruption affects a multimodal journey sold under a single ticket. The agreement covers delays, cancellations, diversions, missed connections, recalculation of the Estimated Time of Arrival (ETA) when it must be postponed, passenger re-routing, passenger communication, reimbursement, care and assistance, and inter-party financial responsibility. It is not a mandatory contract: TSPs that have signed a STSC are free to use a simplified disruption management arrangement that is provided as part of the STSC template. 

12.3.1 Disruption management process 

When a disruption occurs in a leg of the multimodal journey, the responsible operating TSP must notify the other TSP and the SIGN-AIR platform without undue delay. The notification includes details such as flight or train number, date, affected passengers at PNR level, reason for disruption, and expected duration. The platform may also independently identify a disruption based on live operational data. 

Once the disruption is detected, the SIGN-AIR platform recalculates the estimated time of arrival and assesses the connection feasibility using the applicable minimum connecting time , buffers, and operational data. All disruption-related calculations take place in a Disruption Management Module, which is an external module integrated in the SIGN-AIR platform. If continuation of the journey is deemed no longer feasible, this module generates alternative itineraries, filters them for contractual feasibility , and ranks the feasible options by earliest arrival at the passenger’s final destination. 

The passenger is then informed through the Travel Companion or another communication channel. In line with the applicable legal framework on passenger rights, the passenger is presented with the following options: (a) reimbursement (with the possibility to return to the point of departure), (b) continuation or re-routing to the final destination at the earliest opportunity, or (c) re-routing at a later date. If no contractually feasible re-routing exists, fallback solutions such as taxi services, next-day travel, as well as accommodation and care may be provided. The passenger has the right to choose the option that will be applied, within the boundaries of the contract and the law. The passenger’s rights must be communicated as pre-contractual information, and the passenger must again be informed of those rights at the moment they become applicable in accordance with the circumstances. 

The disruption management process is set out in the clauses of the DMSC. The DMSC is linked to the STSC, and thus the Contracting TSP remains responsible for paying any compensation owed to the passenger. The DMSC includes a clause on financial liability, which sets out whether, and to what extent, the Contracting TSP may recover those amounts from the Operating TSP that is responsible for the disruption. This clause is negotiable. In practice, a railway operator will only accept limited responsibility and will be reluctant to assume full financial liability for a missed flight connection. The TSPs may agree to add specific modalities that are not included in the template. For example, they can agree to offer fast-track or priority-lane services to passengers when a connection is still feasible but at risk. 

After a successful negotiation, this smart contract is signed with a digital signature and stored on the blockchain. 

12.3.2 How the blockchain system executes the DMSC 

The SIGN AIR platform’s blockchain based API supports the DMSC template by creating a traceable, tamper resistant record of disruption related events and evidence of passenger impact. The blockchain module does not replace the legal agreement; instead, it records proofs of operational events and smart contract execution logs that can later be used for audit, reconciliation, dispute resolution and financial settlement. The blockchain module creates a transaction containing proof of the disruption notification, including fields such as unique TSP ID, TSP name, vehicle ID, notified time, initial expected time, initial expected time of arrival, and current expected time of arrival. It may also create a second transaction recording proof of the disruption’s passenger impact, including affected ticket IDs and updated ETAs. 

12.3.3 Completion and post-disruption settlement 

The blockchain design also covers the case where the disrupted journey has been completed. In that case, the disruption manager again calculates affected flights and trains and requests the blockchain module to create proof of transactions. The system records whether the disrupted journey was delayed or not delayed at the end, together with the actual arrival time. 

After completion, the system can notify stakeholders depending on the outcome: if the journey was completed, the airlines and railway operators are notified that a disruption affected passengers; if it was not delayed in the end, they may be notified that the journey completed without delay. This supports post-settlement verification and avoids relying solely on manual reporting. 

12.3.4 Overall execution logic 

In practical terms, the Smart Contract is executed as follows: 

• A disruption is detected by a TSP or the SIGN-AIR platform; 
• The affected TSP notifies the platform with operational and passenger-impact data; 
• SIGN-AIR recalculates the ETA and connection feasibility, taking into consideration the agreed MCT; 
• If the journey is no longer feasible, re-routing options are generated, filtered, ranked, and presented to the passenger; 
• Passenger choices, re-routing, reimbursement, care, and assistance are handled under the DMSC – the DMSC arranges who is responsible from an operational point of view; 
• The DMSC includes an arrangement on the financial responsibility between the TSPs in their internal relationship; 
• The blockchain module records proof of the disruption notification, proof of the events and decisions and proof of affected passengers; 
• After the journey completion, the system records the final disruption outcome, including actual arrival time and whether the journey was ultimately delayed. 

12.4 Smart Contract execution and post-settlement 

The SIGN-AIR platform creates executable Smart Contract actions which will result in automated settlement without user intervention for the following indicative use cases: 

12.4.1 Nominal journey: on time or within allowed delay

For a journey completed without disruption, or within an allowed delay, the use case maps primarily the clause on revenue sharing and financial responsibility between the Contracting TSP and the Operating TSP. The SIGN-AIR platform will receive the journey completion notification, records completion on the platform and blockchain, calculates the revenue allocation, and records settlements on-chain, resulting in automated settlement without user intervention. 

The notification trigger flow aligns with the provisions of the Smart Contract which provide for revenue due to the other TSP to be transferred after the passenger’s travel date, and, which requires financial records and sales reporting. The clause on financial responsibility between the parties is relevant if costs, reimbursements, or compensation need to be allocated between the parties. 

12.4.2 Disruption before departure 

This use case is mapped to the contract clause on cancellation by an operating TSP of a scheduled segment. The STSC registers the disruption on the SIGN-AIR platform and the blockchain. This will act as the trigger for the necessary subsequent actions. The STSC notifies the TSP and the passenger (via its Travel Companion or via different means if technically unfeasible), and it collects the passenger’s choice between (a) contract termination with refund and (b) re-routing to the final destination. It records the passenger’s decision per ticket, and tracks reimbursement or itinerary changes. 

12.4.3 Same day delay within an acceptable threshold 

For a delay occurring on the day of the start of the following leg of the journey (a “same day” delay) that remains allowed within the agreed allowed threshold, the use case treats the journey as nominal. The STSC processes the journey as successful and may send a reassurance notification to the passengers. The use case is referenced to the contract clause on revenue sharing between the TSPs because no refund, re-routing, or compensation workflow is triggered. 

12.4.4 Same day delay exceeding threshold 

For a delay occurring on the day of the start of the following leg of the journey, that renders the onward connection infeasible, the use case transitions from a nominal journey flow into a disruption workflow. It first evaluates whether fast-track or priority handling can preserve the connection. If not viable, the STSC triggers disruption handling, collects the passenger’s choice between compensation (including a return service to the point of departure) and re-routing to the final destination, and executes the selected outcome. 

The clauses on disruption management will be triggered, which govern delay and disruption handling, passenger notification, re-routing, missed connections, and - where certain time thresholds are exceeded - accommodation (overnight hotel stay), care (meals and refreshments), and assistance. The legal framework on passenger rights will constitute the minimum services that must be provided to the passenger. If compensation is due to the passenger, the DMSC shall determine the extent to which the responsible Operating TSP will reimburse any costs to the Contracting TSP. 

12.4.5 Same day cancellation 

The “same day” cancellation use case is mapped to the contract provisions concerning cancellations. The STSC registers the cancellation on-chain, which will trigger the necessary actions. It notifies the stakeholders and prompts the passenger to choose between (a) reimbursement (with a return to the point of departure) and (b) re-routing to the final destination (at the earliest opportunity or at a later date). It computes compensation where applicable, and records the outcome. 

12.4.6 Force majeure event 

When a force majeure event occurs, the software code of the “force majeure use case” will be mapped to the force majeure clause of the STSC, which provides that neither party is liable for unavoidable extraordinary circumstances causing delays or disruptions. In execution terms, the STSC registers the event which is the trigger for the relevant actions, it notifies the TSPs and the passengers, and it applies the exceptional rule that compensation is not due where the force majeure condition applies. 

12.4.7 Journey re-routing and adjustment 

The re-routing use case maps to the relevant contract provisions on delay and disruption handling, re-routing options, missed connections, and the passenger’s choice. The STSC registers the updated itinerary, computes the time difference, applies the relevant contract clauses, and records the recalculated obligations on-chain. 

This corresponds to the Smart Contract clauses which cover the automatic determination of feasible alternative re-routing options, and the passenger’s selection through the Travel Companion between: contract termination with reimbursement, re-routing at the earliest opportunity, and re-routing at a later date. 

13. Post-settlement 

In the post-settlement phase, the SIGN-AIR platform provides the TSP with an overview of all tickets sold under a specific STSC for a specific period in a post-settlement dashboard. Sold tickets are submitted to the platform via the passengers' Travel Companion. The dashboard also provides an overview of the revenue and the number of tickets with disruptions, and it indicates the financial liabilities between the TSPs. 

14. Overall execution model 

The STSC template creates a legal framework while the use cases translate selected clauses into automated workflows such as event detection, clause mapping, automated execution, user interaction, on-chain recording and final financial settlement. 

15. Conclusion 

The SIGN-AIR project represents a significant and concrete step towards closing the gap between the EU's multimodal mobility ambitions and the practical reality of data sharing and contractual cooperation between heterogeneous transport operators. By combining standardised contract templates, automated smart contract execution, blockchain-based audit trails, as well as integrated data conversion and timetable synchronisation tools, the platform addresses simultaneously the technical, contractual and operational barriers that have long prevented airlines and railway operators from offering genuinely integrated multimodal services at scale. 

By building a Catalogue of Catalogues instead of a central data hub, and by integrating tools such as TransiTool and the multimodal synchronisation module, the platform enables TSPs to exploit existing EU data sharing obligations and standards while retaining control over their own datasets. The STSC and DMSC translate complex future proof regulatory requirements on multimodal passenger rights into concrete clauses and executable workflows, including revenue sharing, liability allocation and disruption handling 

Against the backdrop of a rapidly developing regulatory framework - including the proposed EU regulation on multimodal passenger rights, the Data Act, the MDMS initiative, and the broader European Mobility Data Space - SIGN-AIR provides both a practical toolbox and a proof of concept: it demonstrates that B2B data sharing and automated contract execution between transport modes are technically and legally feasible, and that the building blocks for single-ticket multimodal travel and intermodal disruption management can be put in place today, ahead of the regulatory obligations that are likely to follow. The SIGN-AIR solution lowers the technical and legal barriers for TSPs to create single multimodal contracts at scale, and it lays the groundwork for more consistent passenger protection across door-to-door journeys. 

That said, a number of challenges remain. The regulatory environment is genuinely in flux. The multimodal passenger rights proposal has not yet been adopted. The platform's approach to GDPR consent management through a token-based system via Travel Companion apps is pragmatically sound but has not yet been stress-tested at scale. A platform that is as forward-looking and innovative as SIGN-AIR, and that operates at the intersection of a rapidly evolving technological and regulatory landscape, will by definition be subject to continuous regulatory change. This is not a weakness but an inherent characteristic of innovation in a heavily regulated sector: the regulatory framework will always be catching up with - or, at times, running ahead of - the technology. For SIGN-AIR, staying attuned to those developments and building sufficient adaptability into its contractual and technical architecture is therefore not a one-off exercise but an ongoing operational reality.