EDI Messaging Protocols: AS2, SFTP, OFTP2, AS4 and the rest

An EDI protocol governs how a business document travels between two trading partners. It is a separate question from what the document says: the EDI standard defines the structure and vocabulary of the message, while the protocol defines how it is packaged, secured, transmitted and acknowledged. A UN/EDIFACT ORDERS message and an ANSI X12 850 can both travel over AS2, and the same AS2 connection can carry either.

In practice a supplier rarely chooses its protocol. The trading partner specifies it, and a supplier trading with several retailers often has to support more than one. What follows is an overview of the protocols in current use, the ones that persist in specific industries, and the services that are frequently described as protocols but are not.

The Applicability Statement family

The Applicability Statement specifications were produced to move EDI off value-added networks and onto the public internet, using cryptography rather than a private network for security. All four sign and encrypt the payload with S/MIME and return a signed receipt, called a Message Disposition Notification, that gives the sender non-repudiable proof of delivery.

AS1 transmits EDI over SMTP email. It was the first of the family and is now largely historical, because email delivery gives no timing guarantee.

AS2 transmits over HTTP or HTTPS and is defined in RFC 4130. It is the dominant protocol in grocery and general merchandise retail, and it is what most large retailers mean when they ask a supplier for a direct connection. The MDN can be requested synchronously, returned on the same HTTP connection, or asynchronously over a separate one. Because both parties exchange certificates and fixed endpoints, AS2 requires coordinated setup and certificate renewal on both sides.

AS3 transmits over FTP and is defined in RFC 4823. It sees limited use, generally where an organisation had existing FTP infrastructure and wanted the AS security model on top of it.

AS4 is a web services profile built on the OASIS ebMS 3.0 messaging specification. It is the most recent of the family and matters chiefly because it is the transport underneath Peppol, which makes it increasingly relevant to European e-invoicing regardless of what a company uses for retail EDI.

File transfer protocols

Plain file transfer remains common, particularly for higher-volume batch exchange and for connections between a business and its own systems rather than between two companies.

FTP transfers files over TCP with no encryption of either credentials or payload. It should not be used across the public internet for commercial documents, though it still appears on internal networks.

FTPS adds TLS to FTP. It keeps FTP’s separate control and data connections, which makes it comparatively awkward to pass through firewalls and NAT.

SFTP is the SSH File Transfer Protocol, a subsystem of SSH rather than a version of FTP. It uses a single connection on one port, which makes it materially simpler to firewall than FTPS, and it is the most widely used file transfer option in EDI after AS2.

SCP also runs over SSH but only copies files, with no directory listing or resumption. It is rarely specified for EDI.

None of these carry an application-level receipt. Where proof of delivery matters, it has to come from the document layer instead, typically a CONTRL or 997 acknowledgement message returned by the recipient.

OFTP and OFTP2

The Odette File Transfer Protocol was developed by Odette International for the European automotive industry. The original ran over X.25; OFTP2, defined in RFC 5024, runs over TCP/IP and adds TLS, file-level encryption, signing and signed receipts.

OFTP2 remains the standard requirement across European vehicle manufacturers and their supply chains. A supplier trading with both automotive and grocery customers will generally need OFTP2 and AS2 side by side.

Value-added networks

A value-added network is a commercial intermediary that operates store-and-forward mailboxes. Each partner connects once to the network rather than establishing a direct connection to every counterparty, and the network handles routing, protocol translation and retention between them.

VAN services are often listed alongside protocols, which confuses two different things. OpenText Trading Grid, formerly GXS Trading Grid Messaging Service, and IBM Sterling, which absorbed the older IBM Information Exchange, are services reached over a protocol such as AS2, SFTP or FTPS, not protocols in themselves. What distinguishes them commercially is that they typically charge per document or per kilocharacter, which is why the cost of a VAN connection scales with volume in a way a direct connection does not.

APIs and web services

Where a system needs to exchange data continuously rather than in scheduled batches, an HTTPS API is increasingly used in place of a file transfer. Documents are posted and retrieved as individual requests, usually authenticated with a token, and the response is immediate rather than deferred to the next polling cycle.

APIs are common between a business and its own platform or ERP, and between a business and a logistics provider. They are much less common between two trading partners directly, because there is no agreed cross-industry API specification for order and invoice exchange in the way that AS2 and EDIFACT are agreed. In most cases an API sits on the internal side of an integration while a conventional EDI protocol handles the partner side.

Peppol

Peppol is a four-corner network for cross-border e-invoicing and procurement, governed by OpenPeppol. A sender connects to an access point, which delivers to the recipient’s access point over AS4, with the participant registry resolving where a given recipient’s documents should go.

It differs from bilateral EDI in that a business connects once to an access point rather than negotiating a connection per partner, and it is mandated for public sector procurement in a growing number of European countries. Peppol defines both a transport and its own document specification, Peppol BIS, which is why it appears in both protocol and standard lists.

Legacy and adjacent technologies

X.400 is an ITU-T messaging suite that carried a substantial share of EDI traffic before the internet protocols displaced it. It survives in a small number of long-running government and aviation systems.

OpenPGP is not a transport protocol. It is an encryption and signing format, defined in RFC 4880, applied to a file before that file is sent over something else. Partners commonly specify PGP-encrypted files over SFTP, which gives payload encryption independent of the transport.

RosettaNet is a consortium and a set of Partner Interface Processes for the electronics and semiconductor supply chain. Its RosettaNet Implementation Framework defines message packaging over HTTPS, so it functions as a business process specification with a transport attached rather than a general-purpose protocol.

Choosing between them

The decision is usually made for you. A retailer publishes its requirement and a supplier meets it, which is why the practical question is rarely which protocol is best but how many a business has to run at once.

Where there is a genuine choice, the distinctions that matter are whether the protocol provides its own delivery receipt, since AS2, AS4 and OFTP2 do and file transfer does not; whether the cost model scales with volume, which separates VAN connections from direct ones; and what the operational burden looks like once it is running, which for AS2 and OFTP2 mostly means certificate expiry, and for SFTP mostly means key rotation and access management.