About ten million people are currently involved in cross-border civil proceedings. e-CODEX provides them with easy access to legal means and boosts judicial cooperation by improving the interoperability between legal authorities within the European Union.
The judicial sector has been lagging behind in terms of digitalising procedures and cross- border cooperation. In an increasingly digital society, cross-border judicial cooperation relies on e-Justice solutions to facilitate the interaction between different national and European actors in legal procedures. e-CODEX offers a European digital infrastructure for secure cross-border communication and information exchange in criminal and civil law.
Modern information and communication technology will make the justice system more efficient and helps people assert their rights more quickly and easily.
Services provided by e-CODEX allow secure communication and information exchange between Member States in the field of justice. The broader vision of e-CODEX is that any citizen or legal professional in the European Union could communicate electronically with any legal authority, including communication of legal authorities with each other.
The e-CODEX system is presently being implemented for European investigation and payment orders, small claims procedures, the mutual recognition of financial penalties and for custodial sentences. In addition, experts are exploring e-CODEX as the transmission system for the secure exchange of electronic evidence between judicial authorities in criminal matters.
By harmonizing the different approaches within the EU countries e-CODEX will improve the efficiency of cross-border information exchange. The main benefits are increased security and reliability along with saving time in completing cross-border processes. This improved efficiency could also support innovations by legal authorities.
The final outcome of e-CODEX will be an interoperable environment building upon national systems and infrastructures supporting the e-Justice activities, especially the European e-Justice Portal and the activities of the e-Justice Action Plans.
The e-CODEX partners are continually looking for ways to achieve better results and to fulfil the mission of all e-CODEX related projects. In other words, we are looking for additional partners to gain full transparency, participation and collaboration for public services within the EU. If your organisation would like to cooperate or contribute to e-CODEX, please contact our marketing & communication manager.
e-CODEX is currently maintained by an international consortium of EU Member States, European chambers of legal professionals and other institutions. e-CODEX is mostly funded by different grants of the European Commission. However, the consortium aims at establishing a long-term sustainable solution by handing e-CODEX over to an established institution with the European Commission.
One part of an e-CODEX installation is the use of a gateway, which is a prerequisite by e-CODEX but not maintained by it. e-CODEX recommens using the DOMIBUS gateway. This product is maintained by CEF.
As e-CODEX is a decentralised system every participant needs to install its own instance of the e-CODEX components nationally. Therefore the operation of the running system has to be done by the e-CODEX participants itself.
e-CODEX is a decentralised network of e-CODEX access points established with every e-CODEX participant. Without replacing the existing back-end systems in the Members States, e-CODEX interlinks national and European IT systems in the e-Justice domain. Therefore each e-CODEX participant has to set up its own access point to participate in the communication.
The following graphic symbolises the decentralised communication between e-CODEX participants:
There are several European use cases currently in use by e-CODEX participants:
Additional use cases are currently being under investigation or planned:
FD909 – Mutual Recognition of Sentences in Criminal Law
Brussels IIa - Council Regulation on jurisdiction, the recognition and enforcement of decisions in matrimonial matters and the matters of parental responsibility, and on international child abduction - Council Regulation (EC) No 2201/2003
In order to use the full potential of structured e-CODEX messages we recommend to connect it to some national backend solution. However, the "Standalone Connector" that is included in the e-CODEX package provides Member States who don’t have their own national end application with a back-end solution that acts as a digital receiver. With this the participant will be able to digitally receive structured messages. These messages will be stored to the filesystem and can subsequently be processed there.
The technical threshold to start with e-CODEX is quite low.
- For a start you need a virtual (or physical) server environment of your choice with an application server (e.g. Tomcat, Weblogic, Glassfish) and a DB installation (e.g. MySQL, ORACLE) to set up the e-CODEX components in your regular IT-infrastructure. However, we highly recommend to use one dedicated application server per application (gateway, connector, backend solution) to avoid cross-references.
- The gateway needs to be reached from the internet.
- Furthermore you will need some certificates to ensure secured and authenticated transactions. See the FAQ below: "Is e-CODEX a secure solution?" for further information in this regard.
e-CODEX consists of two main elements, which are the Gateway and the Connector.
The basic functionality of the Gateway is e-Delivery, which is the exchange of messages between partners. This functionality is performed by the whole set of modules within the Gateway. Other than the Connector, the Gateway is completely agnostic of the content of messages. This means that the Gateway is at no stage aware of the documents and structure of the message. It only handles some routing data to be able to transport the message to another Gateway.
Some of the functionalities of the Gateway are:
- Receiving/Sending messages from / to backend(s). In case of e-CODEX the backend for the Gateway is the Connector.
- Validating header information of messages.
- Find the correct processing mode (PMode).
- Sign and encrypt messages depending on the configuration in the PMode.
- Transfer messages to other Gateways.
According to its particular settings, each e-CODEX participant must perform some adaptations to the messages. The Connector provided by e-CODEX is a generic set of modules which aims to provide the common functionality which is needed by every piloting MS.
The main functionalities of the Connector are:
- Handling communication with the national implementations: There can be more than one national backend. This allows to have several applications within the national infrastructure to handle different Business Use Cases (e.g. one application for EIO, one for EPO, and so on).
- Process message exchange with the Gateway in both directions (for Domibus Gateway a separate plugin is provided).
- Tracing messages and acknowledging them with ETSI-REM evidences.
- Validating signatures of business documents within the message.
- Creation of a TrustOKToken: This token holds the outcome of the validation of the business document’s signature. It is generated in a human readable format (PDF) and a structured format (XML) and is attached to the message.
- Creation of an ASIC-S container: The business contents of a message are packed together in a container File which gets signed.
- Having awareness of messages unconfirmed: If a message is not confirmed by evidences within a configured time period, the message gets declined and the national backend informed.
The figure describes the e-CODEX high-level infrastructure representation with Member States having several backend solutions, the Connector and the Gateway in place:
Yes! The e-CODEX infrastructure is secured on multiple levels.
- On the transmission level it uses SSL (TLS) to communicate between the national gateways.
- On the message level the AS4 standard (established by the OASIS organisation) is used to create an envelope for the messages which can be transferred securely from gateway to gateway. The authenticity and data integrity is ensured with digital signatures and encryption. e-CODEX uses the WS-Security standard (also established by OASIS) to guarantee this security features.
- On the document level also digital signatures are used to support the integrity and authenticity of documents.
Concerning certificates e-CODEX uses a sophisticated concept where and how different certificates are being used. For details read e-Codex_key_trust_stores.pdf
Yes. This solution could be applied to differentiate between civil use cases (e.g. EPO, SC) and criminal use cases (e.g. MLA, EIO). Reasons to differentiate could be different security requirements for these types of use cases or different competent organisations, that want to operate their own gateway.
Yes, although this configuration has not been tested. Therefore it is not recommended to set up the e-CODEX inftrastructure like this.
Besides, Domibus Connector version 4.0 has been enabled with a multi backend functionality. With this it is possible to connect multiple backend solutions to one Connector. For example, if you have separate backend solutions for EPO and SC in place it is possible to connect both applications to only one connector.
For e-CODEX newcomers we recommend to start with the e-CODEX StarterKit. The StarterKit contains the Domibus Connector with its documentation. Additionally you will need the DOMIBUS Gateway (maintained by CEF) and some sort of business application to create and process received e-CODEX messages. If you do not have a business application in place the e-CODEX StartKit provides you with a small "Standalone Client" which will store received messages simply into your file system and send messages from your files system. This Standalone Client can be used as a showcase application or even as a small e-CODEX client to start your e-CODEX activities. For professional use of e-CODEX we highly recommend to integrate it into your national business applications.
You will also need an infrastracture for e-CODEX like a web container, database, certificates, etc. This infrastructure will depend on your national IT constraints and is also NOT part of the e-CODEX package.
The CfC (Coordinator for Configuration) will need the following information:
|Party ID||A unique party ID for the Gateway|
|Endpoint URL||The URL to the Message Service Handler (MSH) Webservice of the Domibus Gateway|
|IP Range||IP Address Range for incoming and outgoing communication with/to the Domibus Gateway|
|Port||Port for incoming and outgoing communication with/to the Domibus Gateway|
|Supported services||A list of the supported e-Justice services|
|Gateway Certificate||The Gateway certificate containing the complete certificate chain (CA-Certificates) in X.509 format|
|SSL Server Certificate||The SSL Server certificate containing the complete certificate chain (CA-Certificates) in X.509 format|
|SSL Client Certificate||The SSL Client certificate containing the complete certificate chain (CA-Certificates) in X.509 format|
|Connector Certificate||The Connector certificate containing the complete certificate chain (CA-Certificates) in X.509 format|
The data listed above will be incorporated into a file called "configuration.prop". The file will look like this:
#EXAMPLE STRUCTURE FOR CONFIGURATION EXCHANGE
# Country Code for your Country. Example EE for Estonia.
partyId = country_code
# Use Cases(Services) you wish to participate. Example EPO, MLA, SMALL_CLAIMS
services = service
# Endpoint address for your GW webservice
endpoint.uri = endpoint_uri
#Port for endpoint
port = port
# Endpoint IP address used for the message outflow FROM this party. (Multiple IPs or IP range)
endpoint.outflow.ip = endpoint_outflow_ip
# Endpoint IP address used for the message inflow TO this party. (Multiple IPs or IP range)
endpoint.inflow.ip = endpoint_inflow_ip
1. The future e-CODEX participants should start with the national tests:
- Internal tests conducted by developers
- Integration tests of components (Gateway and Connector),
- Business tests of national service provider (producing a document and sending it to the national Gateway).
- Mapping tests will be required if backend application uses other data structures or xml schemas than the e-CODEX ones.
2. Once the national tests are completed, it is recommended to start testing with the Central Testing Platform (CTP) that provides a full e-CODEX test environment for sending and receiving test messages for EPO and ESC.
3. After successfully completing tests with the CTP, participants should indicate their readiness to start basic connectivity tests with other participants. Once the connectivity tests are completed, participants are ready to start the end-to-end tests.
As soon as the end-to-end tests are finalised with at least one piloting partner, testing partners can start tests with the e-Justice Portal. These tests are conducted on the same basis as tests with the piloting countries.
You have defined a list of use cases (e.g. EPO, SC, EIO/MLA) which will be supported. This list has to been announced to the CfC (Coordinator for Configuration) before going live.
Appoint a national contact point. This is a person who is responsible and the first contact for any questions, requests or support. The appointment has to be announced to the CfC before going live.
Sign the Circle of Trust Agreement. This is an agreement that forms the legal basis for the recognition of information exchanges between the e-CODEX participants. The document can be found in our collaboration tool (access on demand). The signed agreement must be sent to the CfC before going live.
Yes, the products of e-CODEX are available for everyone without any charge. Both the Domibus Gateway as well as the Domibus Connector are open source (European Union Public Licence - EUPL v1.2).
The amount of person days/months you need to invest relies heavily on the pre-existing e-CODEX knowledge as well as on the extent of integration into the national e-Justice solutions. The e-CODEX consortium can therefore provide only a set of modules that have to be done with a rough estimation on the effort.
A) For the technical preparation the following tasks need to be done:
|Member State||CEF & Me-CODEX||Effort|
|Clear description of CEF eDelivery and e-CODEX use case specification|
|Clear description of the national technical infrastructure and information management policy|
|Identification of dedicated servers, ports and lines for e-CODEX traffic|
|1 week preparation for at least 2-4 national representatives on e-CODEX documentation||2-4 persons 1 week|
|Preparation for e-CODEX team on a MS national technical infrastructure and information management policy||2 persons 1 week|
|Workshop for MS technical team and e-CODEX team to exchange views and make planning||2-4 persons 2 days|
B) The preparation per procedure needs the following tasks:
|Member State||CEF & Me-CODEX||Effort|
|Workshop for MS experts on 1st legal procedure on e-CODEX and e-CODEX experts on process and data modelling||4-6 persons 2 days|
|e-CODEX and MS technical team to set up and test e-CODEX gateway in Member State||1 week|
|Adjustment MS back end solution||to be specified|
|Experts to configure and test MS e-CODEX connectors in Member States||1 week|
|Preparation Go LIVE||1 day|
|Go LIVE||1 day|
These figures are only an indication, Me-CODEX or European Commission cannot be held responsible if practice in a Member State differs from the estimation. The Me-CODEX consortium would like to stress the importance of having at hand the “Clear description of the national technical infrastructure and information management policy” and “Identification of dedicated servers, ports and lines for e-CODEX traffic” before any planning and operational activities to set up e-CODEX start. The experiences from the Member States that have the e-CODEX gateway and connector in place is that the set up lasted longer than indicated in the table because of unclarity of these two policy items.
There are several funding opportunities for e-Justice projects. The most relevant calls are provided by the European Commission itself and by INEA (Innovation and Networks Executive Agency), which was created by the European Commission in 2006 to manage the technical and financial implementation of its TEN-T programme. Get in contact with us for detailed information on funding possibilities or go to the particular websites: