CEN/TS 17011-4:2025
(Main)Electronic Public Procurement - Architecture - Part 4: Technical architecture
Electronic Public Procurement - Architecture - Part 4: Technical architecture
The purpose of this deliverable is to specify and describe the reference architecture applied as the basis for the development of Business Interoperability Interface specifications in the eProcurement domain by the TC 440 technical committee.
Elektronische öffentliche Auftragsvergabe - Architektur - Teil 4: Technische Architektur
Der Zweck dieses Dokuments besteht darin, die Referenzarchitektur festzulegen und zu beschreiben, die vom Technischen Ausschuss TC 440 als Grundlage für die Entwicklung von Spezifikationen für geschäftliche Interoperabilitätsschnittstellen im Bereich der elektronischen Auftragsvergabe verwendet wird.
Marchés publics électroniques - Architecture - Partie 4 : Architecture technique
Elektronska javna naročila - Arhitektura - 4. del: Tehnična arhitektura
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-september-2025
Elektronska javna naročila - Arhitektura - 4. del: Tehnična arhitektura
Electronic Public Procurement - Architecture - Part 4: Technical architecture
Elektronische öffentliche Auftragsvergabe - Architektur - Teil 4: Technische Architektur
Marchés publics électroniques - Architecture - Partie 4 : Architecture technique
Ta slovenski standard je istoveten z: FprCEN/TS 17011-4
ICS:
35.240.20 Uporabniške rešitve IT pri IT applications in office work
pisarniškem delu
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
FINAL DRAFT
TECHNICAL SPECIFICATION
FprCEN/TS 17011-4
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
July 2025
ICS 35.240.63
English Version
Electronic Public Procurement - Architecture - Part 4:
Technical architecture
Marchés publics électroniques - Architecture - Partie 4 Elektronische öffentliche Auftragsvergabe -
: Architecture technique Architektur - Teil 4: Technische Architektur
This draft Technical Specification is submitted to CEN members for Vote. It has been drawn up by the Technical Committee
CEN/TC 440.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
Warning : This document is not a Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 17011-4:2025 E
worldwide for CEN national Members.
FprCEN/TS 17011-4:2025 (E)
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviated terms . 7
5 Alignment with the European Interoperability Reference Architecture (EIRA). 7
5.1 General . 7
5.2 Mapping between EIRA Components, Architecture Building Blocks and the 4-Corner
Model . 8
6 The 4-Corner Model. 10
6.1 General . 10
6.2 The 4-CornersPe . 10
6.3 SMP & SML. 11
6.4 Transaction process . 12
6.5 Advantages . 12
7 Transport infrastructure . 13
7.1 Legal requirements . 13
7.1.1 General . 13
7.1.2 Transparency and Non-Discrimination . 14
7.1.3 Data protection and privacy . 14
7.1.4 Electronic identification and trust services . 14
7.1.5 Security standards . 14
7.1.6 Archiving and traceability . 14
7.2 ASiC-E container . 15
7.2.1 General . 15
7.2.2 mimetype . 15
7.2.3 sbdh.xml (SBDH) . 15
7.2.4 Business documents . 15
7.2.5 Additional documents . 15
7.2.6 META-INF/asicmanifest*.xml . 16
7.2.7 META-INF/signature*.p7s . 16
7.2.8 Additional rules . 16
7.2.9 ASiC-E example . 16
7.3 Encryption of Tender and Qualification documents . 17
7.4 REM Evidence Profile . 17
7.5 SBDH Profile . 18
8 Pre- and post-award Interoperability Architecture . 18
8.1 Transition between pre- and post-award . 18
8.2 ePO mapping . 18
8.3 Mapping between different syntax bindings . 32
9 Process Control Architecture . 33
9.1 General . 33
FprCEN/TS 17011-4:2025 (E)
9.2 Extending process control to post-award . 34
9.3 Seamless integration across phases . 34
10 Security and Data Privacy (Covered as part of 7) . 35
11 Integration with other systems . 35
12 Compliance and regulation (Covered as part of 7) . 35
13 How to claim conformance . 35
Annex A (informative) Overview of the clauses and subclauses which fall under derivative use
............................................................................................................................................................................. 36
Bibliography . 37
FprCEN/TS 17011-4:2025 (E)
European foreword
This document (FprCEN/TS 17011-4:2025) has been prepared by Technical Committee
CEN/TC 440 “Electronic Public Procurement”, the secretariat of which is held by DIN.
This document is currently submitted to the Vote on TS.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document falls under a CEN-CENELEC pilot on derivative use (as approved by the CEN/CA
(Administrative Board) through decision 37/2019). For more information about the implementation of
derivative use in CEN/TC 440 see here: https://www.cencenelec.eu/areas-of-work/cen-cenelec-
topics/public-procurement/cen-tc-440-electronic-public-procurement/
This document is part of a series of multi-part documents prepared, or under preparation, by
CEN/TC 440:
— 17011-series: eProcurement Architecture, providing a set of specifications outlining different
aspects of the eProcurement architecture for Business Interoperability Specifications.
— 17014-series: eTendering Business Interoperability Specifications, providing a set of
specifications outlining business choreography, transaction, syntax binding specifications and
guidelines required to support the eTendering processes.
— 17015-series: eCatalogue Business Interoperability Specifications, providing a set of
specifications outlining business choreography, transaction, syntax binding specifications and
guidelines required to support the eCatalogue processes.
— 17016-series: eOrdering Business Interoperability Specifications, providing a set of
specifications outlining business choreography, transaction, syntax binding specifications and
guidelines required to support the eOrdering processes.
— 17017-series: eFulfilment Business Interoperability Specifications, providing a set of
specifications outlining business choreography, transaction, syntax binding specifications and
guidelines required to support the eDelivery processes.
The terms “shall”, “shall not”, “should”, “should not”, “may”, “can” and “cannot” are interpreted according
to the CEN-CENELEC Internal Regulations Part 3:2022, Clause 7 .
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
https://boss.cen.eu/reference-material/refdocs/pages/
FprCEN/TS 17011-4:2025 (E)
Introduction
Derivative use pilot
This publication falls under a CEN-CENELEC pilot on derivative use (as approved by the CEN/CA
(Administrative Board) through decision 38/2019).
CEN has the copyright to all CEN publications, including their entire content and associated metadata, as
described in CEN-CENELEC Guide 10 “Policy on dissemination, sales and copyright of CEN-CENELEC
Publications”. However, through the derivative use pilot, CEN gives permission to the copying, replication
and translation of content from CEN/TC 440 deliverables in specific circumstances.
Under the derivative use pilot, specific sections of CEN/TC 440 publications may be copied, replicated
and translated in cases where this is a necessary condition for the meaningful implementation of the
publication. The sections which fall under derivative use will typically be elements, such as semantic
definitions and rules related to the use of information elements, and the name, definition and description
of processes and transactions, which are needed in software solutions, whether intended for sale in the
private market or for use in the public sector, and documents guiding the implementation and use in
specific countries and/or business sectors.
Under derivative use, any use of content, which has been copied, replicated or translated from a
CEN/TC 440 publication, should comply with the intended use of the publication. Derivative use cannot
be applied in use cases other than those the publication is intended to support. The intended use of this
publication is set out below.
Intended use of this publication
This document has been developed for any organization looking for guidance on the implementation and
use of electronic procurement deliverables as well as for organizations developing or implementing
software applications related to electronic procurement, such as software providers, business entities
and national authorities. These software applications should be in conformance with this publication.
Parts of the document to which derivative use apply
Each subclause, which falls under derivative use, will be clearly marked with a footnote. The degree to
which the specific content can be modified is specified in CEN/TS 17011-3 , Electronic Public
Procurement — Architecture — Part 3: Customization Guideline.
Annex A provides an overview of the line number references to all subclauses of the publication which
fall under derivative use.
Under preparation.
FprCEN/TS 17011-4:2025 (E)
1 Scope
The purpose of this deliverable is to specify and describe the reference architecture applied as the basis
for the development of Business Interoperability Interface specifications in the eProcurement domain by
the TC 440 technical committee.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 639, Code for individual languages and language groups
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
agent
person, organization, or system that act in procurement or have the power to act in procurement
[SOURCE: eProcurement Ontology]
3.2
business process
sequence or network of activities and collaborations between two or more agents
3.3
business process variant
specification of a business process belonging to a choreography
Note 1 to entry: Different variants may support different electronic information exchange or collaborations. Agents
may publicly advertise their capability to support one or more variants in an automated fashion.
3.4
choreography
set of business processes having the same goals
3.5
collaboration
interaction between two or more agents that result in the exchange of data between the agents involved
as part of a business process
3.6
role
part played by an agent in a particular business process, including its responsibilities (options and
obligations) to perform certain activities and collaborations in that business process
FprCEN/TS 17011-4:2025 (E)
Note 1 to entry: The role is used to show the division of labour and responsibility amongst the agents involved in
the process or within the organization of an agent.
3.7
state
set of options and obligations of the participating agents at a defined step in a business process to perform
specific activities and collaborations
Note 1 to entry: Additional information: an activity of an agent or a collaboration may cause the transition of one
state to another in a predefined set of next steps.
3.8
transaction
content of data exchanged or shared between the agents in a collaboration
Note 1 to entry: A transaction is the atomic unit that leads to a synchronized state in the information systems of
collaborating agents. It is the basic building block to define the choreography between agents. When an agent
recognizes an event that changes the state of a business object within a business process, it uses a transaction to
synchronize with the collaborating agent. A transaction therefore changes the state of a business process. It carries
the intention of the initiating agent and is represented by a data structure that is defined by a data model. The
exchange of a transaction may alter legal obligations between business partners.
4 Symbols and abbreviated terms
For the purposes of this document, the following symbols and abbreviated terms apply.
ABB Architectural Building Block
IoP Interoperability
EIF European Interoperability Framework
EIRA European Interoperability Reference Architecture
5 Alignment with the European Interoperability Reference Architecture (EIRA)
5.1 General
The European Interoperability Reference Architecture (EIRA) provides a structured framework that
supports the design and governance of interoperable systems across various domains. By leveraging
EIRA, the proposed architecture ensures compliance with the principles of the European Interoperability
Framework (EIF) and alignment with European initiatives such as CEF eDelivery. EIRA’s structured
approach, which organizes systems into Architecture Building Blocks (ABBs), enables the reuse of
capabilities, promotes harmonization, and reduces redundancies.
EIRA defines five primary views—Legal, Organisational, Semantic, Application, and Infrastructure—that
guide system design. For this architecture, the focus primarily lies on the Application and Infrastructure
views. The Legal and Organisational views, although integral to the overarching EIF framework, are
indirectly supported through compliance with existing regulatory requirements, such as GDPR, eIDAS,
and public procurement directives, and through the implementation of process choreographies that
manage stakeholder interactions.
The Application and Infrastructure views are particularly relevant to the technical aspects of the
architecture. These views describe how procurement documents are securely transmitted, processed,
and stored across decentralized platforms, ensuring seamless integration with existing European
solutions. For example, the architecture utilizes secure messaging and transport mechanisms, such as
ASiC-E containers, in accordance with established standards. By aligning with EIRA’s infrastructure
FprCEN/TS 17011-4:2025 (E)
specifications, the architecture supports robust data exchange protocols and ensures interoperability
across different platforms.
Semantic interoperability, a critical layer of EIRA, ensures shared understanding of the data exchanged
within eTendering systems. This aspect is already extensively covered in CEN/TS 17011-5, which defines
the semantic model and associated syntax bindings. By integrating these provisions, the architecture
avoids duplicating efforts while ensuring full compliance with EIRA’s Semantic view. The semantic
specifications ensure consistent interpretation and processing of procurement data, enabling
interoperability at both technical and organizational levels.
Alignment with EIRA also involves identifying relevant ABBs and integrating them into the architecture.
Common ABBs such as eSignature Verification and Validation Services, eTimestamp Creation Services,
and secure transport mechanisms are reused wherever applicable. Where domain-specific needs exceed
the capabilities of existing ABBs, additional specifications are developed to extend EIRA building blocks.
For instance, tender document encryption and the handling of REM evidence profiles are tailored to meet
the specific requirements of the pre-award procurement phase while maintaining coherence with EIRA’s
principles.
5.2 Mapping between EIRA Components, Architecture Building Blocks and the 4-Corner
Model
In the 4-Corner model, the exchange of eProcurement documents is mediated through intermediaries,
each operating within a distinct domain. This decentralized architecture requires a robust transport layer
supported by trust services, reliable communication protocols, and standardized semantic models. The
EIRA alignment ensures that these components adhere to a unified framework, enabling smooth
interaction between all stakeholders. The model's reliance on interoperable systems demands careful
mapping of its components to EIRA’s building blocks, including Infrastructure Security Enablers, Data
Source Enablers, Transition Enablers, Collaboration Enablers, Administration Enablers, and Discovery
Enablers.
Infrastructure Security Enablers form the foundation of secure communication between the four corners
of the model. Trust Service Provisioning Components, such as eIDAS-compliant services for eSignature
and eSeal validation, authenticate messages and guarantee their integrity. e-Timestamp Creation Services
verify the chronology of interactions, which is essential for regulatory compliance and trust management
(REM Evidence e.g.). Secure Data Exchange Services ensure encrypted and protected communication
between intermediaries, safeguarding the data from unauthorized access. These enablers are
indispensable for the proper functioning of the transport layer, which connects the decentralized entities
in the 4-Corner model. Without them, the model would be vulnerable to data breaches, fraud, and
compliance issues, undermining the trust that intermediaries provide to buyers and suppliers.
Infrastructure Data Source Enablers facilitate access to shared resources across the system. Metadata
registries and semantic models enable consistent interpretation of messages, ensuring alignment across
different corners. Shared repositories support the reuse of information, streamlining processes and
reducing redundancies. These enablers ensure that data flows remain consistent, accurate, and reusable
within the architecture.
Transition Enablers address the challenge of integrating legacy systems with modern interoperable
standards. By translating proprietary formats into interoperable models through syntax bindings, the
architecture ensures that existing systems can function within the 4-Corner model without significant
redesign. This flexibility maintains continuity for stakeholders who operate older systems while allowing
them to participate fully in standardized exchanges.
Collaboration Enablers are integral to managing the interactions between intermediaries in the 4-Corner
model. The choreography specifications detailed in CEN/TS 17011-5 define the flow of processes, such
as order submissions and validation exchanges. This ensures that all corners operate cohesively,
adhering to the choreography's predefined rules and maintaining process alignment across domains.
FprCEN/TS 17011-4:2025 (E)
Infrastructure Administration Enablers provide the necessary tools for monitoring and managing the
system. Response messages enable intermediaries to notify stakeholders about the status of their
transactions, enhancing transparency and ensuring timely issue resolution. Monitoring tools maintain
the operational health of the transport layer and provide early detection of potential errors, ensuring that
the system operates smoothly and reliably.
Discovery Enablers ensure that participants in the 4-Corner model can identify and integrate with other
entities dynamically. Service directories allow stakeholders to discover endpoints and capabilities,
simplifying the process of onboarding new participants and facilitating the seamless scaling of the
architecture.
Within the 4-Corner model, Infrastructure Security Enablers are the most critical to its success. The
decentralized nature of the model places a heavy reliance on the transport layer to establish trust and
ensure data integrity. Services such as eIDAS-compliant trust mechanisms, eTimestamp creation, and
secure data exchange protocols underpin the reliability and security of interactions. These enablers
safeguard the system against threats, maintain compliance with regulatory requirements, and ensure
that all four corners operate with confidence in the security of their communications.
Figure 1 visualizes the most important EIRA ABB discussed in the text above.
Figure 1 — Simplified Infrastructure Layer
This alignment supports semantic, technical, and organizational interoperability in compliance with the
EIF. By focusing on the Application and Infrastructure views while leveraging semantic provisions from
CEN/TS 17011-5, the architecture remains consistent with EIRA’s objectives and ensures its
interoperability with other European public procurement solutions.
FprCEN/TS 17011-4:2025 (E)
6 The 4-Corner Model
6.1 General
The 4-Corner Model is a fundamental framework in the context of CEN/TC 440, providing a robust
structure for ensuring interoperability and seamless exchange of information in digital procurement
processes. This model is designed to facilitate the secure and efficient transmission of documents and
data between trading partners, while also allowing for flexibility and scalability. The 4-Corner Model
consists of four primary components: the Sender, the Sender's Service Provider (also known as the
Sender Access Point), the Receiver's Service Provider (Receiver Access Point), and the Receiver.
6.2 The 4-CornersPe
The first component, the Sender, is the originator of the document or data. This could be a business or
any organization that needs to send information, such as invoices, purchase orders, or other transactional
documents. The Sender is responsible for ensuring the accuracy and completeness of the information
being transmitted. The role of the Sender is crucial as it initiates the entire transaction process and
ensures that the data complies with relevant standards and formats.
The second component is the Sender's Service Provider, also referred to as the Sender Access Point. This
entity acts as an intermediary that facilitates the secure transmission of data from the Sender to the
Receiver's Service Provider. The Sender Access Point is responsible for validating if the received data
conforms to a standardized format that is compatible with the transport network. These standardized
formats are defined by CEN in the form of transaction specification. This conversion ensures that the data
can be seamlessly integrated into the Receiver's systems, regardless of any differences in the underlying
technology. The Sender Access Point also adds a layer of security by encrypting the data and ensuring it
is transmitted through secure channels.
The third component, the Receiver's Service Provider, also known as the Receiver Access Point, functions
similarly to the Sender Access Point. It receives the data from the Sender's Service Provider, decrypts it,
and converts it into a format that is compatible with the Receiver's systems. The Receiver Access Point
ensures that the data is accurately and securely transmitted to the Receiver, maintaining the integrity
and confidentiality of the information throughout the process. This component is vital in enabling
interoperability between different systems and ensuring that the data can be seamlessly integrated into
the Receiver's business processes.
Finally, the fourth component is the Receiver, the end recipient of the data or document. The Receiver
can be a business or any organization that needs to process the information received from the Sender.
The Receiver is responsible for integrating the data into their internal systems and using it for various
business processes. The efficiency and effectiveness of the 4-Corner Model depend on the Receiver's
ability to accurately process and utilize the information received.
Notably this structure allows for decentralized management of Access Points, enabling flexible
participation of all parties. Figure 2 visualizes the basic structure of the 4-Corner model
FprCEN/TS 17011-4:2025 (E)
Figure 2 — 4-Corner Model
6.3 SMP & SML
In the 4-Corner Model, the SMP (Service Metadata Publisher) and SML (Service Metadata Locator) play
crucial roles in ensuring the seamless and efficient exchange of electronic documents between trading
partners. These components are essential for the discovery and routing of messages within a
decentralized and interoperable digital infrastructure.
The Service Metadata Publisher (SMP) serves as a decentralized registry that stores metadata about
document types and the service providers that handle each type of document. This includes detailed
information about which service providers are responsible for sending and receiving specific document
types, such as invoices, purchase orders, or delivery notices. The SMP also holds the Access Point (AP)
IDs of these providers, enabling the accurate routing of documents. For a provider to be discoverable
within the network, they must register their Access Point in an SMP server. By doing so, they make their
services known to other entities within the ecosystem, facilitating the automatic and efficient exchange
of documents. The decentralized nature of the SMP ensures that there is no single point of failure,
promoting robustness and resilience within the infrastructure.
On the other hand, the Service Metadata Locator (SML) is the centralized component of the infrastructure
that complements the decentralized nature of the SMP. The SML's primary function is to maintain a
registry of records made to the SMP, using the Domain Name System (DNS) to make these records
accessible. When a document needs to be sent, the SML helps locate the relevant SMP where the
recipient's metadata is stored. This DNS-based lookup mechanism allows for quick and reliable discovery
of service metadata, ensuring that documents are routed accurately and efficiently.
The SML operates as a directory service, mapping identifiers to specific SMP records. When a sender
needs to transmit a document, the SML is queried to determine the appropriate SMP that contains the
recipient's service metadata. This process involves resolving DNS entries that correspond to the
recipient's identifier, which then points to the correct SMP server. By centralizing the metadata location
FprCEN/TS 17011-4:2025 (E)
function, the SML provides a cohesive and streamlined approach to managing the discovery process
across the entire network.
Together, the SMP and SML form a cohesive system that underpins the operational efficiency of the 4-
Corner Model. The SMP enables the decentralization of metadata storage, ensuring flexibility and
scalability, while the SML provides a centralized mechanism for locating and accessing this metadata.
This combination ensures that electronic documents are routed correctly and efficiently, supporting
interoperability and seamless communication between disparate systems. The integration of these
components allows for a highly resilient and adaptive infrastructure, capable of handling the complex
demands of modern digital procurement and document exchange processes.
6.4 Transaction process
The transaction process within the 4-Corner Model is designed to ensure the secure, efficient, and reliable
exchange of electronic documents between trading partners. This process involves several key steps,
beginning with the preparation of the message and concluding with its processing by the recipient. Each
step is crucial for maintaining the integrity and authenticity of the transaction.
The process begins with C1, the sender, preparing a valid message according to the syntax binding of a
specific transaction specification. This specification dictates the format and structure of the message,
ensuring that it meets the required standards for interoperability. If legally required, the message is
encrypted to protect its contents during transmission. The encrypted message is then encapsulated in an
ASIC-Container, which serves as a secure digital envelope ensuring that the message is tamper-proof and
maintains its integrity during transit.
Once the message is prepared, C1 submits it to C2, the sender's service provider. Upon receipt, C2
performs a validation check on the message to ensure it conforms to the required standards and
specifications. This validation step is critical as it helps prevent errors and ensures that only compliant
messages proceed through the transaction process. If the validation fails, C2 refuses the message and
returns it to C1 with information regarding the validation errors, enabling C1 to correct and resubmit the
message.
After successful validation, C2 performs a look-up in the Service Metadata Publisher (SMP) to identify the
Access Point (AP) of the relevant service provider for the recipient, C4. The SMP contains metadata about
service providers and the types of documents they handle. If no entry is found in the SMP for the
recipient's AP, C2 returns the message to C1, indicating that the recipient could not be located.
The SMP relies on the Service Metadata Locator (SML) to provide DNS information necessary for locating
the appropriate SMP records. The SML acts as a central directory service that maps identifiers to specific
SMP records. By querying the SML, the SMP receives the necessary DNS information to identify the
recipient's service provider.
With the relevant AP information obtained, C2 transports the message to C3, the recipient's service
provider. Upon receiving the message, C3 attaches a Registered Electronic Mail (REM) evidence to the
message. The REM evidence serves as proof of the message's transmission, providing legal and non-
repudiation evidence that the message was sent and received.
C3 then sends the message to C4, the final recipient. C4 processes the file according to their internal
systems and requirements. If the message was encrypted, C4 opens it after the tendering due-date,
ensuring that the contents remain confidential until the appropriate time. This step is particularly
important in tendering processes, where maintaining the confidentiality of bid information is crucial.
6.5 Advantages
The 4-Corner Model offers significant advantages during the pre-award phase of procurement processes,
enhancing efficiency, security, and compliance. One of the key benefits is its decentralized network
structure. Unlike centralized systems that are prone to single points of failure and bottlenecks, the 4-
Corner Model distributes responsibilities across multiple independent entities. This decentralization
FprCEN/TS 17011-4:2025 (E)
ensures robustness and resilience, allowing the network to maintain functionality even if individual
components encounter issues. Each service provider in the network can operate autonomously,
improving scalability and reducing dependency on any single entity.
Another major advantage is the transaction of standardized documents. The 4-Corner Model mandates
the use of uniform standards for document formats and protocols, as specified by the European
Committee for Standardization (CEN). This standardization ensures that documents such as tenders, bids,
and contracts are consistently formatted, facilitating seamless interoperability between different systems
and organizations. It minimizes errors and misunderstandings, making the entire procurement process
more efficient. Organizations can easily integrate with the network, reducing the time and cost associated
with document exchange.
Furthermore, the 4-Corner Model ensures the secure transport of documents, adhering to the stringent
standards of CEN and pre-award regulations. Security is paramount in the pre-award phase, where
sensitive information such as bid details and tender specifications must be protected. The model employs
robust encryption and secure channels for data transmission, safeguarding against unauthorized access
and tampering. By using trusted service providers for document exchange, the model guarantees that the
data remains confidential and intact from sender to receiver.
7 Transport infrastructure
7.1 Legal requirements
7.1.1 General
The pre-award phase of public procurement involves a complex interplay of legal regulations designed
to ensure transparency, fairness, and security. These regulations govern the transport infrastructure
used to exchange procurement documents, and adherence to them is crucial for maintaining the integrity
and legality of the procurement process. The technical means of the transport infrastructure to fulfil these
requirements are described in 7.2-7.5.
In the pre-award phase, legal requirements typically focus on ensuring that all procurement processes
are conducted in a transparent and non-discriminatory manner, providing equal opportunities for all
vendors. For example, legal frameworks such as the EU Procurement Directive or national procurement
laws mandate the use of secure, standardized communication channels for the submission of tenders,
ensuring that bids are received and processed without tampering or undue influence. The transport
infrastructure must ensure confidentiality, data integrity, and non-repudiation of documents exchanged
between tenderers and contracting authorities. These legal requirements also often specify the need for
auditing trails, ensuring that the entire process can be monitored and verified for compliance at any time.
The technical architecture supporting this phase must therefore be robust and capable of ensuring
compliance with these legal frameworks. This involves using secure transport layers, encryption, and
authentication mechanisms to ensure that data is protected throughout the entire procurement lifecycle.
The infrastructure also needs to support the validation of the submitted documents against predefined
standards and specifications, helping prevent errors or fraudulent activities.
However, legal requirements do not stop with the pre-award phase. Once a contract is awarded, the post-
award phase also carries its own set of legal obligations that must be carefully addressed. These post-
award requirements generally focus on monitoring contract performance, ensuring that both parties
adhere to the terms of the agreement, and maintaining compliance with financial and auditing standards.
Legal frameworks may require the documentation of contract execution, including the reporting of
milestones, payment schedules, performance reviews, and acceptance of goods or services.
For the post-award phase, the legal infrastructure needs to support mechanisms that track and validate
the completion of contract deliverables, ensuring that goods and services meet the required
specifications and timelines. Digital signatures, audit logs, and secure communication channels are again
FprCEN/TS 17011-4:2025 (E)
crucial to maintain the integrity of the entire process. In addition to ensuring compliance with financial
regulations such as VAT and payment terms, the post-award phase also involves the management of
dispute resolution procedures and the enforcement of contract amendments or penalties in case of non-
compliance.
Thus, the technical architecture must not only address the pre-award legal requirements but also extend
to the post-award phase, ensuring that all contractual obligations are met and documented. This includes
the secure exchange of contract updates, progress reports, invoices, and payment authorizations.
Ensuring compliance with legal frameworks throughout the full procurement cycle fosters trust between
stakeholders, reduces the risk of legal challenges, and enhances the transparency and fairness of the
entire procurement process.
7.1.2 Transparency and Non-Discrimination
One of the fundamental principles underpinning public procurement is transparency. Legal frameworks,
such as the European Union's Public Procurement Directives, mandate that all stages of the procurement
process must be open and transparent. This means that the transport infrastructure must facilitate the
clear and accessible exchange of documents, ensuring that all potential bidders have equal access to the
same information. Non-discrimination is also crucial, requiring that all bidders are treated equally,
without favoritism or bias. The transport system must ensure that no bidder is disadvantaged by the
method or timing of document exchanges.
7.1.3 Data protection and privacy
The General Data Protection Regulation (GDPR) sets stringent requirements for the handling of personal
data within the EU. During the pre-award phase, this includes the protection of sensitive information
related to bidders and procurement documents. The transport infrastructure must implement robust
encryption and secure transmission protocols to safeguard this data against unauthorized access and
breaches. Compliance with GDPR also means that bidders’ data must be handled in accordance with
principles of data minimization, purpose limitation, and a
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.