OFTP2 explained: the automotive industry's EDI protocol

What is OFTP2?

OFTP2 (Odette File Transfer Protocol 2) is a session-based file transfer protocol built on TCP/IP that securely exchanges EDI and other business data between trading partners. It was developed by Odette International and remains the dominant communication protocol in the European automotive sector. If you've received a partner spec from a car maker that mentions "OFTP2 mandatory," this is what they're talking about.

The protocol didn't appear out of nowhere. The Odette File Transfer Protocol was defined in 1986 by working group four of the Organisation for Data Exchange by Tele-Transmission in Europe to address the electronic data interchange requirements of the European automotive industry, originally designed around the X.25 network standard. That original version, OFTP1, worked fine for its era but had no native encryption and depended on expensive X.25 or ISDN lines. OFTP2 was written in 2007 by Data Interchange as a specification for the secure transfer of business documents over the internet, ISDN and X.25 networks, and is formally defined in RFC 5024. Today it's used by thousands of companies for global secure data exchange, implemented by the majority of automotive OEMs including Audi, BMW, Daimler, Ford, Hyundai, MAN, Scania, Skoda, Stellantis, Volkswagen and Volvo along with most large Tier 1 suppliers.

Where OFTP2 sits in the EDI stack

OFTP2 is a transport protocol, not a data standard. It doesn't care whether the file inside is EDIFACT, VDA, X12 or a raw CAD drawing. Think of it as the truck, not the cargo. The truck moves the box from A to B securely; what's packed inside that box (a DELFOR forecast, a VDA delivery schedule, an INVOIC invoice) is a completely separate question governed by EDIFACT or VDA syntax rules, which is a topic for its own post.

This distinction trips people up constantly. Someone says "we're moving from OFTP2 to EDIFACT" and that sentence doesn't actually make sense, it's like saying you're moving from a delivery van to an address format. What they usually mean is they're changing the payload standard while keeping the same transport, or vice versa. Keep the layers separate in your head and half the confusion in OEM technical specs disappears.

OFTP2 vs AS2: the comparison everyone searches for

The short answer: AS2 pushes one file per HTTP transaction and only travels in one direction per connection, while OFTP2 opens a session and can push and pull files from both sides before closing it. OFTP2 runs as a session-based system that allows files to move between both partners during a single connection, using TCP/IP but also working with ISDN and X.25, whereas AS2 uses HTTP or HTTPS to move data, with each file travelling as a separate message with its own structure and connections operating in a push-only fashion.

Geography and industry explain most of the rest. OFTP2 is often used in Europe's automotive sector, while AS2 built its base in North American retail and consumer goods. Both protocols use certificate-based security, but they get there differently: OFTP2 relies on SSL/TLS technology to prevent messages from being intercepted or falsified, while AS2 secures integrity using hash algorithms.

The building blocks: Odette-ID, SSID and certificates

Every OFTP2 connection identifies itself through a handful of standardized pieces before a single file moves. Getting these wrong is the single most common cause of failed test connections during supplier onboarding.

• Odette-ID: a unique station identifier assigned to each trading partner, used the way an AS2 identifier is used in that protocol.
• SSID (Start Session ID) and SFID: addressing is done via the Odette-ID and the SSID, the parameters exchanged when a session opens, confirming both sides agree on protocol level, credentials and capabilities before data flows.
• TLS/SSL session encryption: the connection layer that keeps the session itself confidential, separate from any file-level signing.
• CA-issued certificates: required for authentication and non-repudiation, issued through recognized certificate authorities under Odette's trust framework.

One reason implementers actually like OFTP2, once they get past the setup, is its restraint. Despite handling very secure exchange of high volumes of data via dedicated servers, OFTP2 is remarkably simple to use compared to other protocols, with only 14 commands. Compare that to the sprawling AS4/ebMS message header structures and you'll understand why some legacy OFTP2 stacks are still running fifteen years later without a rewrite.

Worked example: an OEM-to-supplier exchange over OFTP2

Picture a Tier 1 seat supplier sending a delivery schedule to a German OEM. In the VDA world, this is comparable to an electronic representation of a planning schedule sent to a supplier from a customer (or the reverse, forecast data flowing from OEM to supplier), commonly exchanged as VDA or EDIFACT DELFOR-style messages. That file doesn't travel by email attachment or SFTP drop. It goes over an OFTP2 session, either a direct point-to-point connection between the supplier's B2B gateway and the OEM's, or through a managed EDI provider handling the OFTP2 layer on the supplier's behalf.

Direct connections mean owning the OFTP2 stack, the certificates, and the ongoing interoperability testing yourself. Most mid-sized suppliers instead go through a managed provider. Names you'll see repeatedly in automotive OFTP2 tenders include SEEBURGER, EDICOM, Data Interchange, Cleo and TrueCommerce, all of whom run certified OFTP2 gateways and handle the certificate renewals nobody enjoys doing manually.

Once that schedule triggers a production run, the downstream logistics side kicks in: transport tenders, shipping instructions, carrier bookings. That's where legacy protocols like OFTP2 have to bridge into modern carrier-facing platforms. TMS and multi-carrier platforms such as MercuryGate, Descartes, Transporeon and Cargoson increasingly sit in that gap, translating EDI-driven production signals into API calls that carriers actually consume today.

Do you actually need OFTP2?

If an automotive OEM's trading partner specification names OFTP2, the answer is yes, full stop. There's no negotiating around a mandate from Volkswagen or BMW. Outside that world, the calculus changes.

• Retail, healthcare or general North American trading partners: AS2 or a REST API is far more common, and OFTP2 would be unusual overhead.
• Automotive Tier 1/Tier 2 suppliers: OFTP2 is close to unavoidable, and you should budget for it during any ERP or EDI platform migration.
• Adjacent manufacturing and logistics sectors: OFTP protocols are also used in industries such as banking, chemical industry and transportation, so don't assume it's automotive-only if a partner in another vertical asks for it.

The bigger trend worth watching: OFTP2 isn't going anywhere for OEM-mandated exchanges, but non-mandated partners are increasingly onboarded through API-first methods instead, with the OFTP2 layer reserved for the legacy relationships that require it. That's the hybrid reality most EDI teams are already operating in, whether they've named it that or not.

FAQ

Is OFTP2 being replaced by APIs? Not for OEM-mandated automotive exchanges. Non-mandated partners increasingly skip it in favor of API-first onboarding, but existing OFTP2 mandates aren't disappearing soon.

Can OFTP2 carry both EDIFACT and X12 payloads? Yes. OFTP2 is payload-agnostic, it transports whatever file format the trading partners agree on, EDIFACT, VDA, X12, XML or CAD data.

What's an Odette-ID and how do I get one? It's the unique station identifier used to address your OFTP2 connection, issued through Odette International or via your EDI provider during onboarding.

Is OFTP2 only for automotive? Primarily, but it also shows up in logistics, government and other manufacturing sectors that adopted it for its reliability and compression handling.

How much does implementing OFTP2 cost? Running your own OFTP2 infrastructure means certificate management, interoperability testing and gateway software licensing. Most suppliers instead pay a managed EDI or VAN provider a recurring fee to handle the protocol layer entirely, trading capital cost for a predictable operating expense.