EDI protocols — which transport for which case?

Five families dominate EDI transport in 2026: AS2, AS4, OFTP2, SFTP and VAN. Each sits at a different trade-off between security, latency, cost, governance and sectoral compliance. This page arms the decision.

Five EDI transport families

Transport is the weakest link in any EDI project: a bad choice gets paid for over ten years in renewed certificates, partner migrations and audits. We define each family first, then weigh them against criteria.

AS2 — the internet reference

AS2 (Applicability Statement 2) is an IETF applicability statement specified by RFC 4130 in July 2005 by D. Moberg (Cyclone Commerce) and R. Drummond (Drummond Group). It describes how existing standards — HTTP/1.1, MIME, S/MIME, MDN — combine to exchange "structured business data" between two known partners. Concretely, an EDI payload (EDIFACT, X12, XML or any MIME type) is S/MIME-signed, optionally encrypted, posted over HTTPS, and acknowledged by a signed MDN (Message Disposition Notification) containing a MIC (Message Integrity Check). It is that MIC, recomputed identically on both sides, that yields non-repudiation of receipt (NRR, RFC 4130 §2.3.1).

AS2 is today dominant in retail (Walmart has mandated AS2 to its entire supplier base since 2002, Target, Carrefour, Lowe's do the same), in US healthcare (HIPAA exchanges flow massively through AS2), and in logistics. The dedicated AS2 page details the full anatomy of an exchange, the sync/async MDN mechanics, and the role of Drummond certification.

AS4 — SOAP successor, PEPPOL foundation

AS4 is an OASIS profile published in 2013 on top of the ebMS 3.0 (ebXML Messaging Services) specification. Where AS2 lives on plain HTTP + MIME, AS4 lives on HTTP/SOAP 1.2 with WS-Security for signature and encryption, and WS-ReliableMessaging for delivery guarantees. That brings two new things on top of AS2: a reliable receptionist (exactly-once delivery with retries controlled by the spec, not by the client) and native interoperability with the WS-* ecosystem (declarative security policies, Web Services Description Language to describe entry points).

AS4 became mandatory in 2018 inside the PEPPOL eDelivery network (4-corner model for European e-invoicing), and it is gradually gaining ground as national e-invoicing mandates converge — Belgium Jan 1, 2026, France September 2026, Germany 2025. Outside PEPPOL, AS4 remains a minority versus AS2, which is simpler to implement.

OFTP2 — European automotive

OFTP2 (Odette File Transfer Protocol version 2) is specified by RFC 5024 (May 2007) under the aegis of Odette International, the standards body for European automotive. It succeeds OFTP 1.3 (RFC 2204, 1997) which lived on X.25 and ISDN; OFTP2 ported the protocol to TCP/IP and added encryption and signature based on CMS (RFC 3852). Operations go beyond simple file send: OFTP2 handles restart on interruption (critical for large automotive files), multi-hop routing between mailboxes (useful in automotive multi-tier subcontracting), and signed end-to-end delivery receipts (EERP, End-to-End Response).

OFTP2 remains the de facto standard between OEMs (Renault, Stellantis, Volkswagen, BMW, Mercedes-Benz) and their tier-1 to tier-3 suppliers in Europe. It carries EDIFACT messages in the Odette format (a subset of EDIFACT) for JIT (Just-In-Time) and synchronous flows (DELJIT, DELFOR). Outside European automotive, its usage is very marginal.

SFTP — operational simplicity

SFTP (SSH File Transfer Protocol) is defined by IETF secsh-filexfer drafts and carried by any SSH server compliant with RFC 4253 (the SSH Transport Layer Protocol). It is a generic file transport, SSH-encrypted, authenticated by password or public key — not by S/MIME certificate as AS2 or OFTP2. SFTP knows nothing about EDI messages: it carries opaque files. All application-level security (payload signature, application acknowledgment) must therefore be added by bilateral convention: an orders-CTRL000042.edi file is dropped in a directory, a control file orders-CTRL000042.ok or .contrl comes back — no universal standard.

Despite this functional poverty, SFTP represents a significant share of real EDI exchanges in 2026, especially for low-volume flows, intra-group flows, reporting flows, and quick deployments where a full AS2 infrastructure would be over-engineered. It is the default protocol whenever you step out of major sectoral mandates.

VAN — historical intermediation

A VAN (Value-Added Network) is a third-party operator that handles EDI routing between partners. Born in the 1980s — IBM Information Network, GE Information Services, AT&T EDI*Net — the VAN model has each partner connect to their VAN mailbox via any protocol (X.25 historically, FTP, AS2, SFTP today), and lets the VAN handle internal routing between connected partners. The operator bills per byte or per transaction.

Historical VANs (IBM Sterling, OpenText/GXS, BT INS) coexist in 2026 with more modern platforms (Cleo, Edicom, Pagero, Stedi) that play a similar role but are positioned commercially as "cloud EDI" or "EDI-as-a-service". The VAN remains the norm in some regulated sectors (US healthcare, banking) and at large groups that prefer a single operator for a thousand partners. Marginal cost and added latency remain its main handicap against direct AS2 or OFTP2 transport.

Decision matrix

Choice criteria

A few practical rules to orient the choice:

• You're a supplier to a North American or European major retailer: AS2 is expected, unless the buyer mandates a specific VAN. Drummond certification is recommended.
• You're an automotive supplier in Europe: OFTP2 is expected for JIT flows, AS2 is admitted for secondary flows. Renault, Stellantis, VW mandate it for tier-1.
• You send or receive B2B/B2G invoices in Europe: sooner or later you will join PEPPOL eDelivery over AS4. The directive is converging (FR 2026, BE 2026, DE 2025, ES 2026-2027).
• Low volume, single partner, limited project: SFTP fits perfectly, with a clear bilateral convention for the acknowledgment.
• A thousand partners, regulated sector, central audit requirement: a modern VAN (Stedi, Cleo, Edicom, Pagero) absorbs multi-protocol orchestration complexity and gives a unified log.
• You exchange via cXML (Ariba, Coupa, SAP Business Network): the transport is direct HTTPS with mutual TLS authentication and cXML signatures — no AS2, no OFTP2. The cXML payload carries its own responses.

RFC and specifications of reference

Each family rests on public documents that can be read verbatim:

• RFC 4130 — AS2, MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP. The canonical AS2 text; rfc-editor.org/rfc/rfc4130.txt (99,857 bytes, archived in content/_sources/rfc/rfc4130_AS2.txt).
• RFC 5024 — OFTP 2, ODETTE File Transfer Protocol 2.0; rfc-editor.org/rfc/rfc5024.txt (276,953 bytes, archived in content/_sources/rfc/rfc5024_OFTP2.txt).
• RFC 3335 — AS1, the SMTP predecessor of AS2. Still referenced for some asynchronous MDN-by-email patterns; rfc-editor.org/rfc/rfc3335.txt (59,687 bytes, archived in content/_sources/rfc/rfc3335_AS1.txt).
• OASIS ebMS 3.0 / AS4 Profile — the AS4 specification and its PEPPOL profile; docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile.
• RFC 4253 — The Secure Shell (SSH) Transport Layer Protocol, the cryptographic base of SFTP. rfc-editor.org/rfc/rfc4253.
• RFC 3274, RFC 5402, RFC 6362 — AS2 complements (CMS compression, EDI compression, multiple attachments).

Further reading

• AS2 — detailed anatomy with real HTTP examples.
• Interchange journey — where these protocols sit in the full flow.
• PEPPOL — for the AS4 + European invoicing context.
• Glossary — VAN · Glossary — EDIINT · EDIFACT ORDERS D.96A.
• EDIFACT Validator — to validate the payload carried by any of these protocols.