The Odette file transfer protocol (OFTP) is a peer-to-peer transfer standard introduced in 1986 to streamline electronic data interchange (EDI) for European automakers. OFTP was developed to help businesses transition manual paperwork for documents such as inventory orders, invoices and purchase receipts into digital formats.
Initially used on private value-added networks, OFTP evolved into OFTP2 in 2007, which adds TLS and certificate authentication on a single TCP port for internet traffic. Modern managed file transfer (MFT) servers typically support OFTP/2 alongside SFTP, FTPS and AS2 to allow teams to automate purchase orders, CAD files and delivery notes and receive receipt acknowledgements. This usage, along with proper encryption and logging, ensures that manufacturers can meet security requirements for European ENX and TISAX compliance.
The protocol runs over TCP/IP ISDN or X.25 and wraps each payload in an envelope that records the sender ID, file size, checksum and an optional digital signature. Built-in restart points, compression and signed receipts lower bandwidth use and support unattended exchanges across unreliable links.
Key capabilities of OFTP
OFTP offers a number of features tailored toward electronic data interchange.
Common characteristics you’ll see in this protocol include:
- Bi-directional sessions that allow either node to send or receive in turn, so queues clear without new connections
- Native metadata fields that carry charset version and user codes, so downstream systems map content without rekeying
- Negotiated capabilities at login that define buffer size, security level and file ceiling to avoid mid-transfer errors
- Support for files larger than 9 PB that use 64-bit counters to preserve precision, even on stateless cloud paths
- Time-window rules that can block or permit traffic by day and hour to help cut telecom costs and avoid maintenance clashes
How OFTP differs from other MFT protocols
Compared to other protocols used in a typical MFT server, such as SFTP, FTPS or HTTPS, OFTP offers a number of differences:
- Connection: Uses a single data and control port at 3305, compared to FTPS dynamic port ranges and SFTP’s secure shell (SSH) tunneling exceptions
- Mandatory signed receipts: Creates nonrepudiation evidence so auditors verify delivery and content integrity instead of relying only on file hashes
- Multi-layer security: Encrypts the session with TLS, then signs or encrypts each file with CMS to provide in-depth defense beyond channel-only ciphers
- Multi-step transfer: Allows store-and-forward relays across hubs, so suppliers behind strict firewalls can still exchange data through a series of nodes. Most other protocols require a direct connection to the recipient
- Prioritization: Includes class of service flags that allow senders to push urgent EDI traffic ahead of bulk transfers without extra queues, which is not common in other protocols
Common OFTP use cases
OFTP serves sectors that need predictable, audit-ready file movement of larger volumes of human-readable files across mixed networks and trading tiers.
Examples of how organizations use OFTP include:
- Accounting and payment systems that must supply purchase order and invoice sending and receiving records
- Customs brokers that file transit and export declarations to the EU and UK systems
- Engineering design offices that must push multi-gigabyte CAD assemblies to tooling partners without splitting archives
- Firmware and calibration teams who distribute signed binaries to production lines, where downtime costs thousands per minute
- Just-in-time scheduling to move EDI orders and delivery forecasts between automakers and parts plants with second-by-second traceability
- Records managers who copy signed receipts and payloads to WORM vaults for a decade or longer to meet TISAX evidence rules
Deployment modes for OFTP
OFTP servers can be deployed in a number of environments, including on-premise, a colocation rack or the cloud.
Common deployment modes for OFTP include:
- Direct point to point: Each partner opens port 3305 to the public internet and swaps certificates to validate connections.
- Hybrid mesh: Large enterprises mix point to point with value-added network (VAN) paths based on partner tier and data sensitivity.
- Reverse proxy: An internal OFTP server publishes through a proxy in the DMZ to keep private keys off internet hosts.
- VAN hub relay: Connections land at a provider that stores and forwards files, so small suppliers need only one trust anchor.
Your organization can use these deployment modes to match its risk budget and uptime goals while staying within the single protocol stack.
OFTP FAQs
OFTP was published in 1986 and designed for dial-up X.25 and private TCP links. It runs a single session for control and data, negotiates block size and restart and relies on partner IDs exchanged out of band. Transport security is optional, so the control stream stays clear, which limits the protocol to trusted paths.
OFTP2 arrived in 2007 with mandatory TLS on the same port 3305. It embeds X.509 certificates for mutual authentication, lets senders sign or encrypt each payload with CMS, lifts the file ceiling to 9 PB, introduces SHA-256 digests and mandates signed receipts. These updates make the protocol viable across the public internet while retaining compatibility when both peers support the newer protocol.
The OFTP process occurs when two partners connect on TCP port 3305. During the initial connection, the client and server exchange Odette identifiers and negotiate session details like block size, restart support, compression and security settings. Commands and data share the same channel, so extra ports aren’t opened once the session begins.
Each file is sent in numbered segments inside an envelope that records length, checksum and timestamps. If the link fails, transfer resumes from the last confirmed segment. Upon receipt, the receiver issues an end-of-file report and, after all payloads finish, an end-of-session report.
Under OFTP2, the entire session is covered by TLS, and each envelope can be signed or encrypted with CMS, which brings authentication and confidentiality to internet links.
Yes, under OFTP2. The original 1986 OFTP does not have built-in cryptography and depends on the security of the underlying transport protocol or external VPNs. However, security features are improved with OFTP2, which mandates TLS for the session and lets partners use CMS to sign or encrypt each file.
OFTP2 negotiates ciphers at handshake, applies mutual certificate checks and supports SHA-256 digests and 2048-bit keys. An OFTP2 node can fall back to clear-text mode when a peer uses the previous OFTP version, but while this feature can keep legacy links alive while giving full encryption everywhere else, it is not ideal.
Yes, OFTP maps cleanly to TCP by opening port 3305 and running the same record headers and restart logic used on X.25 and ISDN. This lets partners shift traffic to private or public IP networks without rewriting EDI processes or changing Odette identifiers.
OFTP2 makes TCP/IP the primary transport and layers TLS on the session, which adds certificate checks and stronger digests while keeping the single-port design. Because the core framing remains identical, mixed environments can run clear-text OFTP for legacy peers and encrypted OFTP2 for internet links under one policy set.
