Commission Implementing Regulation (EU) 2026/101 of 15 January 2026 on setting out the technical specifications and other requirements for the decentralised IT system, as referenced in Regulation (EU) 2023/2844 of the European Parliament and of the Council, in relation to the procedures established by the legal acts listed in points 3 and 4 of Annex I, the legal acts listed in points 1, 10 and 11 of Annex II to that Regulation, and to the procedure established by Article 19a of Regulation (EU) 2020/1784 of the European Parliament and of the Council, as introduced by Article 24(3) of Regulation (EU) 2023/2844 of the European Parliament and of the Council for the electronic service of documents through the European electronic access point

Where applicable, the schema shall make use of relevant standards or vocabularies, applied by e-CODEX to provide interoperability, which are necessary for the proper validation of the elements and types defined within this schema. This may include:

• — EU e-Justice Core Vocabulary

• — Aggregated Components

• — Unqualified Data Types

• — A code list for European Union Language Codes

Also, where applicable, the schema may incorporate relevant ETSI standards to make use of their definitions.

Annotations and Documentation

Annotations: Each element in the schema shall typically be accompanied by annotations. These should provide human-readable information about the element, often defining its purpose or usage in a clear and concise manner.

Usage and Adaptability

Modular Structure: Each section shall be designed with specific functionality and may be reused or adapted independently. This should make the schema easy to customise for different use cases.

Extensibility: The schema shall be designed to support the inclusion of new elements or attributes if additional information is needed in the future. This may be achieved by using optional elements and sequences that may be extended without breaking existing implementations.

Adaptable Structure: The schema shall be designed with the purpose of allowing for the addition or modification of elements or data types as necessary. The form’s structure may accommodate changes in requirements without major redesigns.

Optional Elements: Many elements within a form may be marked as optional, meaning they may be included or omitted based on specific circumstances.

The schema shall be designed to support the collection of structured data for specific requests.

Modifications

The schema design shall emphasise flexibility, modularity, and ease of adaptation. The use of complex types and optional elements shall ensure that it may handle diverse scenarios while remaining easy to modify and extend.

3.2.   Statutory Forms

The technical specifications for the data schemas shall define a structured framework for representing the forms, as set out by Directive 2014/41/EU, in XML format.

3.3.   Predefined messages

Predefined messages are representations of exchanges established by Directive 2014/41/EU, but for which no specific form was provided in the legal act. Their types and number will be determined during the business and technical analysis.

Their schemas shall be designed to define a structure of XML Schema Definitions (XSD) ensuring consistency, structure, and compliance with business needs.

The outline of the key components of these schemas shall be the following:

• — The top-level element in this schema shall be named according to the specific message type being defined.

• — The necessary fields required for the specific message type shall be added and defined within this structure, ensuring proper representation of data elements.

3.4.   Free text messages

Free text messages are representations of exchanges that allow for unstructured or partially structured content, enabling flexibility while still adhering to regulatory and business requirements. This schema is designed to define the structure of XML Schema Definitions (XSD) for these messages, ensuring consistency and proper formatting.

The outline of the key components of these schemas shall be the following:

• — The Top-level Section in this schema shall be named according to the specific free text message type being defined.

• — The schema shall define the necessary structure for the free text message while allowing for appropriate ordering of elements as required.

• — The necessary fields required for the specific free text message type shall be added and defined within this structure, ensuring proper representation of data elements.

ANNEX VI

Digital procedural standard for the digitalisation of Regulation (EU) 2018/1805

1. Introduction and scope

Article 3 (9) of Regulation (EU) 2022/850 on a computerised system for the cross-border electronic exchange of data in the area of judicial cooperation in civil and criminal matters (e-CODEX system) defines ‘digital procedural standard’ as the technical specifications for business process models and data schemas which set out the electronic structure of the data exchanged through the e-CODEX access points. The business process model shall be developed, maintained and updated applying the Business Process Model and Notation (BPMN) or other industry-wide standards for business process modelling.

The data schemas shall allow for interoperable data exchanges through e-CODEX.

Therefore, for the purposes of the digitalisation of Regulation (EU) 2018/1805, this Annex shall set out the technical specifications for:

• (a) business process models,

• (b) data schemas.

2. Technical specifications for the business process models under Regulation (EU) 2018/1805

The technical specifications for business process models shall be considered minimum specifications and shall set out the key aspects necessary for enabling electronic communication for the purposes of Regulation (EU) 2018/1805 through the decentralised IT system, and shall include both cross-border communication instances and, where Member States choose to utilise the decentralised IT system for that purpose, those between national actors (e.g. in case of a transmission or receipt through a Central Authority, where applicable).

They shall be as follows:

2.1.   Freezing Order (FO)

Issue and Transmit Freezing Certificate / Order Process model

• — Issue and Transmit a Freezing Order: the issuing authority issues a Freezing Order and sends the respective Freezing Certificate (including a (certified) copy of or a digital original of the FO, where so required by the executing State) to the relevant executing authority(ies) (where applicable, through the designated Central Authority).

• — Provide additional information: the Issuing Authority provides additional information to the Executing Authority (where applicable, through the designated Central Authority);

• — Withdraw a Freezing Order: where the Freezing Order can no longer be recognised and executed or is no longer valid, the issuing authority withdraws the freezing order (where applicable, through the designated Central Authority).

• — Reply to Request to Limit the Period of Freezing: The Issuing Authority responds to the request to limit the period of freezing.

• — Send and receive any other communication needed in the context of a Freezing Order to/from the Executing Authority or where applicable to/from the designated Central Authority.

Receive and Decide on Freezing Certificate / Order Process model

• — Receive a Freezing Order: the Executing Authority receives the Freezing Order (either directly or through a Central Authority of the executing State) and needs to assess the request in order to make a decision on whether to recognise and execute the order.

• — Forward a Freezing Order: in case the Freezing Order has been transmitted to a Central Authority of the executing State, that Central Authority forwards the Freezing Order to the correct Executing Authority and informs the Issuing Authority accordingly.

• — Request additional information: the Executing Authority requests additional information from the Issuing Authority (where applicable, through the designated Central Authority).

• — Extend Time Limits: The Executing Authority informs the Issuing Authority of being unable to meet the time limits (where applicable, through the designated Central Authority).

• — Notify about Decision to Recognise and Execute: the Executing Authority recognises a transmitted Freezing Order (either fully or partially). It takes the measures necessary for its execution and informs the Issuing Authority about its decision (where applicable, through the designated Central Authority). Execution can be postponed on one of the statutory grounds.

• — Inform about Postponement: the Executing Authority informs the Issuing Authority of the postponement of the Freezing Order (either directly or through a Central Authority).

• — Inform about Legal Remedies: the Executing Authority informs the Issuing Authority of invoked legal remedies (either directly or through a Central Authority).

• — Send Execution Report: following the successful execution of the Freezing Order, the Executing Authority sends the execution report to the Issuing Authority (either directly or through a Central Authority).

• — Request to Limit the Period of Freezing: at any time following the execution of a freezing order, the Executing Authority can send a request to the Issuing Authority to limit the freezing period.

• — Notify about the Impossibility to Execute: the Executing Authority notifies the Issuing Authority of the impossibility to execute the Freezing Certificate/Order (either directly or through a Central Authority).

• — Notify about Decision not to Recognise and Execute: The Executing Authority inform the Issuing Authority of its decision not to recognise and execute the Freezing Order (either directly or through a Central Authority).

• — Terminate process upon withdrawal of a Freezing Order by the Issuing Authority (where applicable, through the designated Central Authority).

• — Send and receive any other communication needed in the context of a Freezing Order to/from the Issuing Authority or, where applicable, to/from the designated Central Authority.

2.2.   Confiscation Order (CO)

Issue and Transmit Confiscation Certificate / Order

• — Issue and Transmit Confiscation Order: the issuing authority issues a Confiscation Order and sends the respective Confiscation Certificate (including a copy of or a digital original of the CO, where so required by the executing State) to the relevant executing authority(ies) (where applicable, through the designated Central Authority).

• — Provide additional information: the Issuing Authority provides additional information to the Executing Authority (where applicable, through the designated Central Authority).

• — Withdraw a Confiscation Order: where the Confiscation Order can no longer be executed or is no longer valid, the issuing authority withdraws the confiscation order (where applicable, through the designated Central Authority).

• — Send and receive any other communication needed in the context of a Confiscation Certificate/Order to/from the Executing Authority or where applicable to/from the designated Central Authority.

Receive and Decide on Confiscation Certificate / Order

• — Receive a Confiscation Certificate/Order: upon receipt of the Confiscation Order (either directly or through a Central Authority of the executing State) the executing authority assesses the request in view of its recognition and execution.

• — Forward a Confiscation Order: in case the Confiscation Order has been transmitted to a Central Authority of the executing State, that Central Authority forwards the Confiscation Order to the correct Executing Authority and informs the Issuing Authority about the forwarding.

• — Request additional information: the Executing Authority requests additional information from the Issuing Authority (where applicable, through the designated Central Authority).

• — Extend Time Limits: the Executing Authority informs the Issuing Authority of the reasons for not meeting the time limits, and both agree on an appropriate schedule (where applicable, through the designated Central Authority).

• — Notify about Decision to Recognise and Execute: the Executing Authority recognises a transmitted confiscation order, it takes the measures necessary for its execution and informs the Issuing Authority about its decision (either directly or through a Central Authority). Execution can be postponed on one of the statutory grounds.

• — Inform about Postponement: the Executing Authority informs the Issuing Authority of the postponement of the Confiscation Order (either directly or through a Central Authority).

• — Inform about Legal Remedies: the Executing Authority informs the Issuing Authority of invoked legal remedies (either directly or through a Central Authority).

• — Send Results on Execution: following the successful execution of the Confiscation Order, the Executing Authority sends the results of the execution to the Issuing Authority (either directly or through a Central Authority).

• — Inform about Impossibility to Execute Confiscation Order: the Executing Authority notifies the Issuing Authority of the impossibility to execute the Confiscation Order (where applicable, through the designated Central Authority).

• — Notify about decision not to Recognise and/or Execute: the Executing Authority informs the Issuing Authority of its decision not to recognise and execute the Confiscation Order.

• — Terminate process upon withdrawal of a Confiscation Order by the Issuing Authority (where applicable, through the designated Central Authority).

• — Send and receive any other communication needed in the context of a Confiscation Order to/from the Issuing Authority or, where applicable, to/from the designated Central Authority.

3. Technical specifications for data schemas

The following paragraphs outline the provisions for the technical specifications that shall serve as a basis for developing XML Schema Definitions (XSDs) for the digitalisation of Regulation (EU) 2018/1805. These specifications define the key components, and any other information in order to provide a comprehensive description for the production of these schemas.

The description is intended to be generic allowing the produced XSDs to be modified and extended without requiring changes to these specifications.

The specifications are provided for the statutory forms, any predefined message or free text message used in the exchanges under Regulation (EU) 2018/1805.

3.1.   General Considerations

For all schemas to be provided, the following provisions shall apply:

Versioning

A version attribute shall be included to facilitate schema versioning management. This will allow to update the schema in future iterations as per the business requirements, indicating whether the new version is backward compatible when introducing new features or refinements.

Schema Declaration and Metadata

Where applicable, the schema shall make use of relevant standards and vocabularies, applied by e-CODEX to provide interoperability, which are necessary for the proper validation of the elements and types defined within this schema. This may include:

• — EU e-Justice Core Vocabulary

• — Aggregated Components

• — Unqualified Data Types

• — A code list for European Union Language Codes

Also, where applicable, the schema may incorporate relevant ETSI standards to make use of their definitions.

Annotations and Documentation

Annotations: Each element in the schema shall typically be accompanied by annotations. These shall provide human-readable information about the element, often defining its purpose or usage in a clear and concise manner.

Usage and Adaptability

Modular Structure: Each section shall be designed with specific functionality and may be reused or adapted independently. This shall make the schema easy to customise for different use cases.

Extensibility: The schema shall be designed to support the inclusion of new elements or attributes if additional information is needed in the future. This may be achieved by using optional elements and sequences that may be extended without breaking existing implementations.

Adaptable Structure: The schema shall be designed with the purpose of allowing for the addition or modification of elements or data types as necessary. The form’s structure may accommodate changes in requirements without major redesigns.

Optional Elements: Elements within the form may be marked as optional, meaning they may be included or omitted based on specific circumstances.

The schema shall be designed to support the collection of structured data for specific requests.

Modifications

The schema design shall emphasise flexibility, modularity, and ease of adaptation. The use of complex types and optional elements ensures that it may handle diverse scenarios while remaining easy to modify and extend.

3.2.   Statutory Forms

The technical specifications for the data schemas shall define a structured framework for representing the forms, as set out by Regulation (EU) 2018/1805, in XML format.

3.3.   Predefined messages

Predefined messages are representations of exchanges established by Regulation (EU) 2018/1805, but for which no specific form was provided in the legal act. Their types and number will be determined during the business and technical analysis.

Their schemas shall be designed to define a structure of XML Schema Definitions (XSD) ensuring consistency, structure, and compliance with business needs.

The outline of the key components of these schemas shall be the following:

• — The top-level element in this schema shall be named according to the specific message type being defined.

• — The necessary fields required for the specific message type shall be added and defined within this structure, ensuring proper representation of data elements.

3.4.   Free text messages

Free text messages are representations of exchanges that allow for unstructured or partially structured content, enabling flexibility while still adhering to regulatory and business requirements. This schema is designed to define the structure of XML Schema Definitions shall be established for these messages, ensuring consistency and proper formatting.

The outline of the key components of these schemas shall be the following:

• — The Top-level Section in this schema shall be named according to the specific free text message type being defined.

• — The schema shall define the necessary structure for the free text message while allowing for appropriate ordering of elements as required.

• — The necessary fields required for the specific free text message type shall be added and defined within this structure, ensuring proper representation of data elements.

ANNEX VII

Digital procedural standard for the digitalisation of the procedure under Article 19a of Regulation (EU) 2020/1784, as introduced by Article 24(3) of Regulation (EU) 2023/2844

1. Introduction and scope

Article 3 (9) of Regulation (EU) 2022/850 on a computerised system for the cross-border electronic exchange of data in the area of judicial cooperation in civil and criminal matters (e-CODEX system) defines ‘digital procedural standard’ as the technical specifications for business process models and data schemas which set out the electronic structure of the data exchanged through the e-CODEX access points. The business process model shall be developed, maintained and updated applying the Business Process Model and Notation (BPMN) or other industry-wide standards for business process modelling.

The data schemas shall allow for interoperable data exchanges through e-CODEX.

Therefore, for the purposes of the digitalisation of the procedure under Article 19a of Regulation (EU) 2020/1784, as introduced by Article 24(3) of Regulation (EU) 2023/2844, this Annex shall set out the technical specifications for:

• (a) business process models,

• (b) data schemas.

2. Technical specifications for the business process models under the procedure under Article 19a of Regulation (EU) 2020/1784, as introduced by Article 24(3) of Regulation 2023/2844

The technical specifications for business process models shall be considered minimum specifications and shall set out the key aspects necessary for enabling electronic communication for the purposes of Article 19a of Regulation (EU) 2020/1784, as introduced by Article 24(3) of Regulation (EU) 2023/2844 through the decentralised IT system, and shall include both cross-border communication instances and, where Member States choose to utilise the decentralised IT system for that purpose, those between national actors.

They shall be as follows:

Service through the EEAP

The Court serves documents to the Addressee through the European Electronic Access Point – The Court serves documents to the Addressee who either acknowledges receipt or refuses service based on the language used.

3. Technical specifications for data schemas

The following paragraphs outline the provisions for the technical specifications that shall serve as a basis for developing XML Schema Definitions (XSDs). These specifications define the key components, and any other information in order to provide a comprehensive description for the production of these schemas.

The description is intended to be generic allowing the produced XSDs to be modified and extended without requiring changes to these specifications.

The specifications below are provided for the statutory forms, predefined messages or free text messages used in the exchanges under the procedure under Article 24(3) of Regulation (EU) 2023/2844.

3.1.   General Considerations

For all schemas to be provided, the following provisions shall apply:

Versioning

A version attribute shall be included to facilitate schema versioning management. This will allow to update the schema in future iterations as per the business requirements, indicating whether the new version is backward compatible when introducing new features or refinements.

Schema Declaration and Metadata

Where applicable, the schema shall make use of relevant standards or vocabularies, applied by e-CODEX to provide interoperability, which are necessary for the proper validation of the elements and types defined within this schema. This may include:

• — EU e-Justice Core Vocabulary

• — Unqualified Data Types

• — A code list for European Union Language Codes

Also, where applicable, the schema may incorporate relevant ETSI standards to make use of their definitions.

Annotations and Documentation

Annotations: Each element in the schema shall typically be accompanied by annotations. These shall provide human-readable information about the element, often defining its purpose or usage in a clear and concise manner.

Usage and Adaptability

Modular Structure: Each section shall be designed with specific functionality and may be reused or adapted independently. This shall make the schema easy to customise for different use cases.

Extensibility: The schema shall be designed to support the inclusion of new elements or attributes if additional information is needed in the future. This shall be achieved by using optional elements and sequences that may be extended without breaking existing implementations.

Adaptable Structure: The schema shall be designed with the purpose of allowing for the addition or modification of elements or data types as necessary. The form’s structure may accommodate changes in requirements without major redesigns.

Optional Elements: Elements within a form may be marked as optional, meaning they may be included or omitted based on specific circumstances.

The schema shall be designed to support the collection of structured data for specific requests.

Modifications

The schema design shall emphasise flexibility, modularity, and ease of adaptation. The use of complex types and optional elements shall ensure that it may handle diverse scenarios while remaining easy to modify and extend.

3.2.   Statutory forms

The technical specifications for the data schemas shall define a structured framework for representing form L, as set out by the Regulation (EU) 2020/1784, in XML format.

3.3.   Predefined messages

Predefined messages are representations of exchanges established by the Regulation, but for which no specific form was provided in the legal act. Their types and number will be determined during the business and technical analysis.

Their schemas shall be designed to define a structure of XML Schema Definitions (XSD) ensuring consistency, structure, and compliance with business needs.

The outline of the key components of these schemas shall be the following:

• — The top-level element in this schema shall be named according to the specific message type being defined.

• — The necessary fields required for the specific message type will be added and defined within this structure, ensuring proper representation of data elements.

3.4.   Free text messages

Free text messages are representations of exchanges that allow for unstructured or partially structured content, enabling flexibility while still adhering to regulatory and business requirements. This schema is designed to define the structure of XML Schema Definitions (XSD) for these messages, ensuring consistency and proper formatting.

The outline the of key components of these schemas shall be the following:

• — The Top-level Section in this schema shall be named according to the specific free text message type being defined.

• — The schema shall define the necessary structure for the free text message while allowing for appropriate ordering of elements as required.

• — The necessary fields required for the specific free text message type will be added and defined within this structure, ensuring proper representation of data elements.

ANNEX VIII

Implementation timetable

The implementation timetable referred to in Article 10(1), point (f), of Regulation (EU) 2023/2844 is laid down as follows:

• (a) A release of the reference implementation software that is fully developed, tested, and stable enough to be deployed in a live environment where end users can access it, including the accompanying documentation, shall be made available by the Commission to the Member States by at the latest four months before the date of application of Articles 3 and 4 of Regulation (EU) 2023/2844, set by Article 26(3) of that Regulation;

• (b) Concerning the legal acts in the scope of this implementing Regulation, a release of the Competent courts (authorities) database (CDB) that is fully developed, tested, and stable enough to be deployed in a live environment where end users can access it, including the accompanying documentation, shall be made available by the Commission to the Member States by at the latest four months before the date of application of Articles 3 and 4 of Regulation (EU) 2023/2844, set by Article 26(3) of that Regulation;

• (c) Concerning the legal acts in the scope of this implementing Regulation, the data in Competent courts (authorities) database (CDB) shall be fully updated by the Member States as soon as possible but not later than one month before the date of application of Articles 3 and 4 of Regulation (EU) 2023/2844, set by Article 26(3) of that Regulation;

• (d) The installation of the reference implementation software by the competent authorities shall be concluded at the latest one month before the date of application of Articles 3 and 4 of Regulation (EU) 2023/2844, set by Article 26(3) of that Regulation;

• (e) The adjustments to national IT systems necessary for ensuring compliance with the requirements of the decentralised IT system shall be completed at the latest one month before the date of application of Articles 3 and 4 of Regulation (EU) 2023/2844, set by Article 26(3) of that Regulation.

ELI: http://data.europa.eu/eli/reg_impl/2026/101/oj

ISSN 1977-0677 (electronic edition)