Commission Implementing Regulation (EU) 2026/101of 15 January 2026on 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

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 are provided for the statutory forms, predefined messages or free text messages used in the exchanges under Regulation (EC) 1896/2006.

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 the forms, as set out by Regulation (EC) 1896/2006, 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 Section 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 will be added and defined within this structure, ensuring proper representation of data elements.

Annex

ANNEX III

Digital procedural standard for the digitalisation of Regulation (EC) No 861/2007

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 (EC) No 861/2007, this Annex shall set out the technical specifications for:

(a) business process models,

(b) data schemas.

1. Technical specifications for the business process models under Regulation (EC) 861/2007

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 (EC) 861/2007 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 forward to another competent court or authority).

They shall be as follows:

Request for a European Small Claim Process

Submit a claim – The claimant fills in and submits a claim form (Form A) to the Court;

The claim is outside the scope of the Regulation – The Court informs the claimant in case the claim is outside the scope of the Regulation;

Claimant withdraws the claim – The claimant communicates to the Court that the claim is withdrawn;

Claimant informs the Court that they do not withdraw the claim – the claimant informs the Court that they do not wish to withdraw the claim;

Request by the Court to complete and/or rectify the claim form – The Court request the claimant (Form B) to complete and/or rectify the claim form;

Court dismisses the claim –The Court can also dismiss the claim;

Payments – The parties and the Court communicate regarding the payment of fees;

Forward to competent Court – The Court forwards the claim to the competent Court.

Processing European Small Claims Process

The Court serves the claim form on the defendant – The Court serves the claim form and Form C on the defendant;

The defendant submits a response to the claim – The defendant submits a response to the claim (Form C);

The defendant submits a counterclaim – The defendant submits a counterclaim (Form A);

The Court requires translation of a document – The Court requires translation of a document from the claimant or the defendant;

Oral hearing – The claimant and/or the defendant request an oral hearing which could be decided by the Court, or the Court decides to hold an oral hearing on its own motion;

Extension of a time limit – The claimant and/or the defendant request an extension of a time limit set by the Court and the Court takes a decision on the request;

Judgment by the Court – Judgment by the Court to the defendant and the claimant.

Post-judgment

Appeal – In case an appeal against the judgment is possible under national law, the claimant or the defendant may file an appeal;

Review of the judgment – The defendant may request a review in exceptional cases and the Court decides on the request for review;

Request for certificate – The Claimant or the defendant request the certificate (Form D) from the Court.

1. 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 Regulation (EC) 861/2007.

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 the forms, as set out by Regulation (EC) 861/2007, 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 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 will be added and defined within this structure, ensuring proper representation of data elements.

Annex

ANNEX IV

Digital procedural standard for the digitalisation of Framework Decision 2002/584/JHA

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 Framework Decision 2002/584/JHA, this Annex shall set out the technical specifications for:

(a) business process models,

(b) data schemas.

1. Technical specifications for the business process models under Framework Decision 2002/584/JHA

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 Framework Decision 2002/584/JHA 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).

To ensure compliance with Articles 9 and 10 of Framework Decision 2002/584/JHA, the workflows supporting the business process models described below shall account for the possibility of transmitting an EAW outside the decentralised IT system, including via the Schengen Information System (SIS). However, the actual communication process through such channels is out of scope of this Digital Procedural Standard.

The technical specifications for business process models shall be as follows:

Issue and Transmit EAW Process model

The issuing judicial authority issues and sends an EAW to the competent executing judicial authority in the Member State where the requested person is (believed to be) located.

Receive and Execute EAW Process model

Upon receipt of the EAW, the executing judicial authority assesses the request and decides whether to surrender the requested person to the issuing State or to refuse.

Surrender Requested Person Process model

When the executing judicial authority decides to surrender the requested person they inform the issuing State authorities. This business process also addresses conditional surrender and postponement, as well as transit through the territory of another Member State, where applicable.

Refuse to Surrender Requested Person Process model

When an executing judicial authority decides to refuse to surrender the requested person they inform the issuing judicial authority.

Withdraw EAW Process model

If the issuing judicial authority decides to withdraw the EAW, they notify to that effect the executing judicial authority, where the requested person has been deprived of liberty. Withdrawal may take place after the EAW is issued and transmitted until the surrender is effected.

Prosecution for Other Offences Process model

If an issuing judicial authority intends to prosecute a requested person for other offences (cf. Article 27 of Framework Decision 2002/584/JHA), and provided there is no situation of presumed consent pursuant to Article 27(1) of Framework Decision 2002/584/JHA, the issuing judicial authority makes a request in the meaning of Article 27(4) of Framework Decision 2002/584/JHA.

Surrender to a Third Member State Process model

A third Member State may request the surrender of a person, who has been previously surrendered from one Member State to another. In such cases, the last executing State of the EAW must provide its consent.

Extradition to a Third Country Process model

In accordance with Article 28(4) a person surrendered on the basis of an EAW cannot be extradited to a third State without the consent of the authority of the Member State, which has surrendered the person.

1. 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 Framework Decision 2002/584/JHA. 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 form annexed to Framework Decision 2002/584/JHA, any predefined message, or free text messages used in exchanges under Framework Decision 2002/584/JHA.

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

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 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 the forms, as set out by Framework Decision 2002/584/JHA, in XML format.

3.3.

Predefined messages

Predefined messages are representations of exchanges established by Framework Decision 2002/584/JHA, 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 (XSDs) 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

ANNEX V

Digital procedural standard for the digitalisation of Directive 2014/41/EU

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 Directive 2014/41/EU, this Annex shall set out the technical specifications for:

(a) business process models,

(b) data schemas.

1. Technical specifications for the business process models under Directive 2014/41/EU

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 Directive 2014/41/EU 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.

European investigation order

Issue and Transmit EIO Process model

Issue and Transmit an EIO (Annex A): the Issuing Authority issues an EIO and transmits it to the Executing Authority (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);

Change EIO (Annex A): the Issuing Authority replaces the original EIO with a modified EIO and transmits it to the Executing Authority (where applicable, through the designated Central Authority);

Issue and transmit supplementary EIO (Annex A): the Issuing Authority issues an EIO which supplements an earlier EIO and transmits it to the Executing Authority (where applicable, through the designated Central Authority);

Send a notification message: the Issuing Authority sends a notification about the legal remedies sought against the issuing of an EIO to the Executing Authority (where applicable, through the designated Central Authority);

Withdraw an EIO: the Issuing Authority informs the Executing Authority about withdrawing the EIO in whole (where applicable, through the designated Central Authority);

Request a status update: the Issuing Authority requests a status update about the evolution of the recognition and execution of an EIO from the Executing Authority (where applicable, through the designated Central Authority);

Send and receive any other communication needed in the context of an EIO to/from the Executing Authority or where applicable to/from the designated Central Authority.

Receive and Execute EIO Process model

Receive an EIO and send confirmation of receipt (Annex B): Executing Authority receives the issued EIO from the Issuing Authority and sends confirmation of receipt (where applicable, through the designated Central Authority). In case of a forward of an EIO, this obligation applies both to the authority, which initially received the EIO, including the designated Central Authority, and to the authority to which the EIO was forwarded;

Forward an EIO and inform the Issuing Authority about the forward (Annex B): if the authority, which received the EIO, is not the competent one or is only partially competent, or if the EIO is received by the designated Central Authority (where applicable), the EIO is forwarded to the competent Executing Authority in the Executing State, and the authority, which forwards the EIO, informs the Issuing Authority about the forward (where applicable, through the designated Central Authority);

Return an EIO: where an EIO has not been issued by an Issuing Authority as specified under Article 2(c) of Directive 2014/41/EU, the Executing Authority returns the EIO to the Issuing Authority (where applicable, through the designated Central Authority);

Send a notification message: the Executing Authority notifies the Issuing Authority about a given situation under the following provisions of Directive 2014/41/EU: recital 22, Article 10(4) and (5), Article 12(5) and (6), Article 14(5), Article 15, Article 16(2), points (a), (b) and (c), Article 16(3), point (b), Article 19(2), Article 32(2) and 32(5) (where applicable, through the designated Central Authority);

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

Inform about the progress of an EIO: the Executing Authority informs the Issuing Authority about the progress of the recognition and execution of the EIO (where applicable, through the designated Central Authority);

Send the Results of execution of an EIO: the Executing Authority sends the results of the execution of the EIO (either in whole or in part) to the Issuing Authority (where applicable, through the designated Central Authority);

Refuse an EIO: the Executing Authority informs the Issuing Authority about refusal of EIO (where applicable, through the designated Central Authority);

Terminate process upon withdrawal of an EIO by the Issuing Authority;

Send and receive any other communication needed in the context of an EIO to/from the Issuing Authority or, where applicable, to/from the designated Central Authority.

Issue and Transmit Request for Transit Process model

Issue and Transmit a Request for Transit: the Transit Requesting Authority (an authority of the Issuing State competent to issue a Request for Transit) issues a Request for Transit and transmits it to the Transit Granting Authority (an authority of the Member State of Transit competent to grant transit);

Provide additional information: the Transit Requesting Authority provides additional information to the Transit Granting Authority;

Withdraw a Request for Transit: the Transit Requesting Authority informs the Transit Granting Authority about withdrawing the Request for Transit in whole;

Send and receive any other communication needed in the context of the Request for Transit to/from the Transit Granting Authority.

Receive and Reply to Request for Transit Process model

Receive a Request for Transit: Transit Granting Authority receives a Request for Transit from the Transit Requesting Authority;

Forward a Request for Transit: if the authority, which received the Request for Transit, is not the competent one, it forwards the Request for Transit to the competent Transit Granting Authority;

Request additional information: Transit Granting Authority requests additional information from the Transit Requesting Authority;

Send a reply to the Request for Transit: Transit Granting Authority sends the reply to the Request for Transit (informing of its decision on whether transit is granted) to the Transit Requesting Authority;

Terminate process upon withdrawal of the Request for Transit by the Transit Requesting Authority;

Send and receive any other communication needed in the context of the Request for Transit to/from the Transit Requesting Authority.

2.2.

Interception of Telecommunication Notification (ITN)

Issue and Transmit ITN Process model

Issue and Transmit an ITN (Annex C): The Competent Authority of the Intercepting Member State issues a notification about the interception of telecommunication and transmits it to the Competent Authority of the Notified Member State;

Provide additional information: the Competent Authority of the Intercepting Member State provides additional information to the Competent Authority of the Notified Member State;

Change ITN (Annex C): the Competent Authority of the Intercepting Member State replaces the original ITN with a modified ITN and transmits it to the Competent Authority of the Notified Member State;

Withdraw an ITN: the Competent Authority of the Intercepting Member State informs the Competent Authority of the Notified Member State about withdrawing the ITN in whole;

Send and receive any other communication needed in the context of the ITN to/from the Competent Authority of the Notified Member State.

Receive and Reply to ITN Process model

Receive an ITN: the Competent Authority of the notified Member State receives an ITN from the Competent Authority of the Intercepting Member State;

Forward an ITN: if the authority, which received the ITN is not the competent one, it forwards the ITN to the Competent Authority of the Notified Member State;

Request additional information: the Competent Authority of the notified Member State requests additional information from the Competent Authority of the intercepting Member State;

Send a notification message: the Competent Authority of the notified Member State sends a notification to the Competent Authority of the Intercepting Member State informing about a decision taken that the interception may not be carried out or shall be terminated, and where necessary that any material already intercepted while the subject of the interception was on its territory may not be used, or may only be used under conditions which it shall specify;

Terminate process upon withdrawal of the ITN by the Competent Authority of the Intercepting Member State;

Send and receive any other communication needed in the context of the ITN to/from the Competent Authority of the Intercepting Member State.

1. 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 Directive 2014/41/EU. 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 form, predefined message or free text message used in the exchanges under Directive 2014/41/EU.

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

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

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.

1. 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.

1. 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

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.

1. 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.

1. 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

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.