Basic Data Retrieval Pilot (BDRP)MINISTRY OF MOBILITY AND PUBLIC WORKS (LU)

Overview

The Basic Data Retrieval Pilot is deliberately the simplest thing that can be tested, and that is its value. Before anything multimodal or cross-border can work, an authority has to be able to ask a question and get an answer: locate the right data subset in the registry of identifiers, find the eFTI platform holding it, and retrieve it through the national eFTI Gate. The pilot establishes that baseline for Luxembourg and creates a reference point for more complex integrations later.

Concretely, it queries transport identifiers and retrieves container-level data including origin, destination and status, simulating the kind of queries customs and other competent authorities would make in practice. Around that sit the practical decisions any Member State faces: a lightweight query interface for authorities or an authority access point, backend processing of requests passed from the Gate to the platform, and the choice between AS4 and REST API for retrieval — a decision MMTP is taking together with CFL.

Lead beneficiary

Ministry of Mobility and Public Works (MMTP), Luxembourg

Countries involved

Luxembourg

Transport modes

Road, rail or inland navigation

Main stakeholders

Ministry of Mobility and Public Works · CTIE · Luxembourg Customs and Police · CFL terminals, CFL intermodal and CFL logistics.

eFTI components

eFTI Gate · eFTI Platform · Registry of identifiers. AAP and CA application to be determined

Timeline

Planning beginning 2025
Development mid-2026
Piloting September–October 2026
Results 2026/2027

Status
(summer 2026)

Preparation — conceptual design, documentation and stakeholder alignment
  • Establish and test connectivity between the eFTI Gate and the eFTI Platform.
  • Validate the retrieval of basic datasets, such as shipment and container details.
  • Confirm compliance with eFTI regulation data protocols.
  • Identify potential bottlenecks in data retrieval.
  • Generate insights for refining the data exchange processes.

UC1

Query transport identifiers and retrieve container-level data, including origin, destination and status.

UC2

Query the registry of identifiers to locate the correct eFTI platform.

UC3

Simulate typical competent authority queries to verify data accessibility for customs and other authorities.

As of summer 2026 no technical development or pilot execution had taken place; the work has been conceptual design, documentation and stakeholder alignment. That phase confirmed the scenarios are feasible and identified the interactions between eFTI Gate, Registry of Identifiers and eFTI Platforms as critical to implementation, along with the need to define data models, query parameters and interfaces before development begins.

The pilot is waiting on the final eFTI XSD specifications. In parallel, MMTP is analysing how to implement the Luxembourg eFTI Gate, including collaboration models with other Member States, with the aim of finding the most efficient and scalable approach by leveraging existing solutions and experience. Continuous alignment between MMTP, CTIE, CFL, authorities and platform providers on roles, responsibilities and governance was confirmed as necessary, as was early clarification of technical choices such as AS4 versus REST APIs.