TEL TSI compliance for freight railway undertakings

Under EU 2026/253, a freight RU sends path requests, train composition and train-ready messages, receives the train traffic messages, and exchanges the electronic consignment note (eCN) and, in single wagonload transport, the wagon messages. This applies to domestic and cross-border services. The lead RU of a service also does the tasks of Art. 13(1), such as the consignment note and wagon monitoring. Each RU uses an API or a web UI that follows the common interface specification (Art. 14, Annex pt. 1.7).

The TEL TSI applies to the whole Union rail system (Art. 2(2)), so your domestic services are in scope as well as your cross-border services. The Union rail system is defined in Directive (EU) 2016/797 (Art. 2(1) and Annex I). It does not include metros, trams and light rail, or functionally separate local, urban or suburban networks (Directive Art. 1(3)). Member States may also exclude some networks, for example privately owned infrastructure that its owner uses for its own freight activities (Directive Art. 1(4)). The TEL TSI also does not apply to services to or from a third country that are not subject to similar rules under an international agreement (Art. 2(3)). The register confirms your exact coverage once you select your role and sources.

Start now. Your milestones in Appendix G run from 13 December 2026 (common reference data for organisations and locations) to 9 December 2029 (train composition, train ready, train traffic data, eCN and, in single wagonload transport, wagon messages). Path requests and object identifiers follow on 4 March 2029. Freight RUs also deliver their common sector specification by 30 September 2027 (Art. 21(4)) and report to the Agency by 2 March 2028 (Art. 17(2)(b)). IT procurement and integration with infrastructure manager systems take time, so map your obligations first.

The common interface is a specification, not a central platform. Every API and web UI that a telematics stakeholder deploys must follow it (Annex pt. 1.7(1)). The specification is the ERA technical document ERA-TD-104, referenced in Appendix C, index [104]. For capacity management, train preparation and traffic management, a freight RU exchanges its messages through its own API or through the web UIs that the infrastructure manager must provide (Art. 14(1) and (4)). For the eCN and the wagon data, it uses its own telematics application, and freight RUs may also jointly use a common Union API (Art. 14(6)).

Yes. One plan covers every user in the organisation, and each organisation account is keyed to its official European organisation code. A holding structure runs one account per undertaking. Consultants and auditors join a client's account as members, with the admin's recorded approval.

No. The eFTI Regulation and the TEL TSI are different obligations pointing in different directions. Under the TEL TSI, the electronic consignment note is a requirement you must meet. Under the eFTI Regulation the obligation runs the other way: from 9 July 2027, competent authorities across the EU must accept freight transport information when it is submitted electronically through a certified eFTI platform - but economic operators, including freight railway undertakings, are not required to submit it electronically. eFTI is an option you can take, not a duty placed on you. If you do choose the electronic route, its conditions then attach: a certified eFTI platform, machine-readable data, and a unique access link. The practical upside: the consignment data you are already building for the TEL TSI eCN - consignor, consignee, places, goods, weights, dangerous-goods details - is substantially the same underlying information eFTI covers, so eCN work is a head start on any future eFTI use. The two systems use different technical formats, so a mapping step is required; building the eCN does not by itself make you "eFTI-compliant." Sources: Regulation (EU) 2020/1056, Arts. 4-5 and Art. 16(1); Commission Implementing Regulation (EU) 2026/253.

No. The TEL TSI (Reg. (EU) 2026/253) governs the data exchange: the messages you send and receive for train composition, train readiness, train running, forecasts and interruptions. That is what this tool records. The operational obligations behind those facts come from the OPE TSI (Reg. (EU) 2019/773). For example, OPE point 4.2.3.3.2 requires the railway undertaking to inform the infrastructure manager when a train is ready for access to the network. TEL TSI Annex point 2.5.2 sets out how. The obligation is "deemed to have been fulfilled" without a message in two cases: the train is ready on time according to the working timetable, or Railway Mobile Radio (RMR) or the ETCS L2 "Start of mission" procedure is available as reported in the RINF and mandated by the infrastructure manager of the network of departure through its network statement. When the train is ready late, the railway undertaking must send a TrainReadyMessage. When it is ready early, it may send one. When it is not ready on time, point 2.5.3 also requires a TrainReadyMessage with the status "NotReady". Appendix A.2 of the TEL TSI Annex links train composition (point 2.5.1), train ready (2.5.2), train readiness forecast (2.5.3), train running (2.6.3) and train forecast (2.6.4) to their OPE points. Points 2.6.5 (train delay cause) and 2.6.6 (service disruption) refer to the OPE TSI in their own text. For those messages, OPE creates the duty and the TEL TSI defines the data exchange that implements it. This does not hold for every TEL TSI obligation: the electronic consignment note (point 3.1.1), for example, has no link to the OPE TSI.

The two are also demonstrated in different ways. The OPE TSI is a functional subsystem with no interoperability constituents (OPE point 5.2), and none of its requirements needs a separate assessment by a Notified Body. OPE requirements that refer to structural subsystems and are listed in its interfaces (OPE point 4.3) are assessed under the structural TSIs. Railway undertakings and infrastructure managers demonstrate OPE compliance within their Safety Management System when they apply for a new or amended safety certificate or safety authorisation, and the national safety authority then supervises it (OPE point 6.2.1).

So what you record here shows your readiness to exchange the data the TEL TSI requires. It is not a declaration of compliance: under TEL TSI Article 18, a presumption of compliance comes from a positive result in the web application that ERA provides. It also does not mean that your OPE obligations are met. Those belong in your SMS. Sources: Commission Implementing Regulation (EU) 2019/773 (consolidated version of 31.03.2025), points 4.2.3.3.2, 4.3, 5.2 and 6.2.1; Commission Implementing Regulation (EU) 2026/253, Article 18 and Annex points 2.5.2, 2.5.3 and Appendix A.2.