2.1.

2.2.

2.3.

2.4.

2.5.

2.6.

2.7.

5.1.

5.2.

5.3.

5.4.

5.5.

5.6.

5.7.

5.8.

6.1.

6.2.

6.3.

6.4.

6.5.

6.6.

6.7.

6.8.

7.1.

7.2.

7.3.

7.4.

7.5.

7.6.

(a)

business process models,

(b)

data schemas.

Request for the European Order for Payment Process

Processing European Order for Payment Process

Post- EOP

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:

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.

—

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.

—

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.

(a)

business process models,

(b)

data schemas.

Request for a European Small Claim Process

Processing European Small Claims Process

Post-judgment

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:

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.

—

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.

—

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.

(a)

business process models,

(b)

data schemas.

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.

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:

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.

—

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.

—

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.

(a)

business process models,

(b)

data schemas.

—

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

—

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

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:

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.

—

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.

—

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.

(a)

business process models,

(b)

data schemas.

—

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

—

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

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:

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.

—

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.

—

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.

(a)

business process models,

(b)

data schemas.

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.

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:

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.

—

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.

—

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.

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