Choosing a Protocol for Partner Exchange: A Decision Framework

The request usually arrives as one sentence: "We're starting a data exchange with a new partner — can you set up the file transfer?" Behind that sentence hides a decision that will outlive the project, the contract, and possibly your tenure: which protocol carries the files. Choose well and the exchange hums along unattended for years. Choose badly and you inherit a recurring ritual of failed transfers, confused phone calls with someone else's IT department, and certificate expiries discovered at quarter-end.

What makes partner exchange different from every internal protocol choice is that you only control one end. The decision is a negotiation with another organization's capabilities, policies, and skill levels — so it needs a framework, not a favorite. This article gives you one: a capability survey to send before anything is built, the factors that actually decide the outcome, a scorecard to make the reasoning explicit, and three worked examples covering the partners you are most likely to meet. It is part of our SFTP vs FTPS vs FTP series.

Why Partner Exchange Is Its Own Problem

Inside your own network, a protocol decision is a technical comparison — you weigh SFTP against FTPS on their merits and implement the winner on both ends. (That comparison is its own article: SFTP vs FTPS, the definitive comparison.) Partner exchange adds four constraints that regularly overrule the technical merits:

• Capability reality. The best protocol on paper is worthless if the partner's software, staff, or security policy cannot operate it. A protocol both sides can run beats a protocol one side admires.
• Longevity. Partner integrations calcify. Whatever you agree on will still be running when both original contacts have changed jobs, so operational simplicity compounds over time.
• Shared failure domain. When a transfer fails, diagnosis spans two organizations, two firewalls, and two change-control processes. Every avoidable moving part you accept now is a future cross-company conference call.
• Compliance exposure. Data crossing organizational boundaries is exactly where auditors, regulators, and contracts focus. The protocol choice must be defensible in writing, not just functional.

One consequence up front: plain FTP is off the menu for partner exchange. Credentials and business data in cleartext across networks neither side controls fails every one of the four constraints. The narrow surviving uses of plain FTP are internal and contained, as covered in when plain FTP is still acceptable — a partner link across the internet is not among them.

Step One: Send the Capability Survey

Never design the exchange from assumptions. A ten-question survey, sent to the partner's technical contact before any decision, prevents most late surprises. Copy and adapt this one:

PARTNER FILE EXCHANGE — CAPABILITY SURVEY
------------------------------------------
1. Which transfer protocols can you support? (SFTP / FTPS / HTTPS /
   AS2 / other) — please list all, not just the preferred one.
2. Do you prefer to HOST the endpoint, or CONNECT to ours? Can you
   do either?
3. If connecting to us: will your traffic come from fixed source IP
   addresses we can allowlist? Please list them.
4. Authentication you support: password / SSH key / client
   certificate. How do you prefer to exchange keys or certificates?
5. Are transfers manual (a person) or automated (a scheduler)? What
   software will actually perform them?
6. Expected schedule and volume: how often, how many files, typical
   and maximum sizes?
7. File conventions: naming pattern, folder layout, and how we should
   signal "file complete" (rename on completion? trigger file?).
8. Compliance constraints on your side (frameworks, data residency,
   encryption-at-rest requirements)?
9. Technical contact + escalation path for failed transfers, both
   directions.
10. Can you provide a TEST endpoint or test window before go-live?

Two of these questions matter more than they look. Question 1's phrasing ("list all, not just the preferred") frequently reveals that a partner who "requires FTPS" also supports SFTP — the requirement was really a default. And question 10 is non-negotiable: partners' documentation routinely lags what their systems actually run, and a one-hour test window exposes the gap while it is still cheap to fix.

Step Two: Decide Who Hosts

Every exchange has a server side (which hosts the endpoint and accounts) and a client side (which connects and pushes or pulls files). This choice shapes everything downstream, because the host sets the protocol menu and absorbs most of the operational burden: firewall openings, account management, log retention, and availability.

Prefer to host when the exchange matters to you commercially or involves many partners — hosting gives you the logs, the control, and the ability to standardize. Prefer to connect when the partner is larger or regulated and insists, which they will; enterprises almost always host. When you do host, hosting well means offering a menu rather than an ultimatum: a multi-protocol server such as Sysax Multi Server serves SFTP, FTPS, and FTP from one installation and one user database, so each partner account can use the protocol that side can actually operate, without you running three server products. When you connect, your obligations shrink to a good automation client, keys or credentials handled carefully, and a fixed source IP if the partner allowlists.

A useful default for the direction of file flow, whoever hosts: each side pushes its own outbound files and picks up its own inbound files from a folder on the host. Push-with-rename (upload as a temporary name, rename when complete) is the simplest reliable "file is ready" signal and almost every partner understands it.

Step Three: Weigh the Factors That Actually Decide

Compliance expectations

Most security frameworks and data-handling contracts converge on the same three questions: is the data encrypted in transit, who can access it, and can you demonstrate both afterward? SFTP and FTPS both satisfy encryption-in-transit when configured properly, so between those two, compliance is usually a tie — the differentiation comes from evidence quality (server-side session logs, named accounts per partner, no shared credentials). Two special cases change the answer entirely. Retail, logistics, and healthcare supply chains often mandate AS2, a protocol built around signed, receipted business documents — if your partner says AS2, that is a requirement, not a preference; see our AS2 and EDI pillar. And when the "partner" is really a person who will click a link twice a quarter, a browser-based HTTPS exchange may serve better than any FTP-family protocol; our HTTPS file transfer pillar covers that pattern.

Operational burden, per protocol

Burden is where exchanges quietly succeed or fail, so compare it explicitly:

The firewall row of this comparison deserves its own reading: FTPS's two-connection design makes it the protocol most likely to fail across two organizations' firewalls at once. The mechanics are in the firewall's view of the three protocols.

Authentication logistics

Think through the day-two logistics, not just the mechanism. Passwords are universally understood but need a safe delivery channel and a rotation story. SSH keys exchange easily (the public half is not secret — email is fine once fingerprints are confirmed) and never expire, but someone must remove them when the partner's staff changes. Client certificates offer the strongest mutual authentication and the heaviest paperwork: two organizations' renewal calendars now depend on each other. Whichever you choose, record the exchange procedure in writing during onboarding — the second key rotation should not require archaeology.

The Scorecard

With the survey returned and the factors reviewed, score each candidate protocol per partner. Rate 1 (poor) to 5 (excellent) on each row, multiply by the weight, and total. The weights below suit a typical unattended business exchange; shift them when your situation differs (for a one-off manual exchange, "unattended reliability" drops; for regulated data, "evidence quality" rises).

Do not over-engineer the arithmetic — the scorecard's real job is to force the conversation onto evidence ("their survey says X, the test showed Y") and to leave a written rationale you can hand an auditor or a successor. Ties are broken by the burden table above, which usually means ties break toward SFTP.

Worked Example 1: The Small Vendor

A regional supplier sends you a weekly price file and picks up purchase orders. Their "IT department" is the office manager with a graphical FTP client. No fixed IP. No compliance framework beyond your contract's confidentiality clause.

Survey findings: they can operate any protocol their GUI client supports — which, for every mainstream client, includes both SFTP and FTPS — but they cannot host anything, and certificate or key ceremonies will strain them. So: you host. Your firewall preference then applies, favoring SFTP's single port. Authentication starts as a strong unique password delivered out of band — key authentication is better, but a partner who cannot rotate a key safely gains little from one — with the option to upgrade later. Their client shows the host key fingerprint on first connect; you put the correct fingerprint in the onboarding email so verification is a comparison, not a leap of faith. Decision: SFTP, you host, password now, keys when they are ready. Total partner-side instructions: hostname, port 22, username, password, two folders.

Worked Example 2: The Enterprise Partner

A large customer onboards you into their managed transfer platform. Their onboarding PDF specifies: SFTP, their hosting, SSH key authentication, source IP allowlisting, files pushed by you on a nightly schedule.

There is no protocol decision here to make — enterprises dictate — but the framework still earns its keep on the client side you now own. Generate a keypair and send them the public half (confirming its fingerprint through a second channel); ensure your outbound transfers originate from the fixed address you registered, which may mean pinning the job to a specific egress route; and treat their maintenance windows as part of your schedule design. Because the transfer is nightly and unattended, run it from a real automation tool rather than a script taped to a task scheduler: a connection profile in Sysax FTP Automation holds the host, key, and schedule together, and its retry and error handling covers the platform's occasional maintenance blips without waking anyone. Decision: their SFTP, key auth, your disciplined client-side automation. The main risk to manage is people-shaped: document where the private key lives and who may touch it.

Worked Example 3: The Regulated Counterparty

A healthcare billing partner exchanges files containing regulated personal data with you daily, both directions. Their security questionnaire demands encryption in transit, encryption at rest, named accounts, retained transfer logs, and annual evidence.

Encryption in transit narrows nothing (SFTP and FTPS both qualify), so the decision turns on evidence and lifecycle. Their survey shows a strong preference for SFTP with key authentication — typical for this profile — and your hosting is acceptable to them. The questionnaire's "at rest" line is the interesting one: transport encryption ends at the endpoint, so files sitting in the exchange folder need their own protection. The established pattern is OpenPGP file encryption layered on top of the transfer: each side encrypts outbound files to the other's public key before upload, so files are ciphertext even at rest on the server. This is a standard automation-tool capability — Sysax FTP Automation, for instance, can encrypt and decrypt with OpenPGP as a pre- and post-processing step around the transfer itself. Add per-partner named accounts, retained session logs on the hosting server, and a documented key-rotation procedure, and the questionnaire answers itself. Decision: SFTP with keys, OpenPGP payload encryption, logging and rotation documented. Had this partner been a retail or EDI counterparty demanding signed delivery receipts, the answer would instead have been AS2 — that boundary is explored in our AS2 and EDI pillar.

Close the Loop in Writing

Whatever the scorecard says, the exchange is not done until one page of writing exists per partner: protocol and endpoints, who hosts, accounts and authentication (with rotation procedure and any expiry dates), folder layout and completion signaling, schedule, both escalation contacts, and the date of the last successful end-to-end test. That page is what turns the next failed-transfer incident from archaeology into a checklist — and if the relationship ever migrates protocols, it becomes the inventory input for the migration playbook.

The compact version of this whole framework: survey capabilities before designing anything, decide who hosts, rule out plain FTP for anything crossing organizational lines, score the survivors on evidence, and let ties break toward the protocol with the least recurring burden — usually SFTP, with FTPS a sound answer where the partner's world runs on it, and AS2 where the industry mandates receipts. Then write it down.

Frequently Asked Questions