Setting Technical Standards for Partner Exchange

"How should we connect?" asks the new partner, and the accommodating answer, "whatever works best for you", feels like good service. It is a long-term loan taken out at a terrible rate. Every arrangement you accept becomes permanent. The odd protocol, the peculiar naming, the password-only login all get baked into a production flow. Someone must secure, monitor, and troubleshoot that flow for as long as the relationship lasts. Say yes to everything for a few years and you are running a museum of everyone else's preferences. Admission is free. The upkeep is not.

Mature exchange programs answer the question differently: with a menu. Here are the protocols we offer, the authentication methods we accept, the naming convention your files will follow, and the encryption we require. Pick from these. A menu is not rigidity; restaurants with menus serve more diners, faster and more reliably, than kitchens that cook whatever anyone requests. The trick is designing a menu short enough to operate and generous enough that nearly every partner finds a workable option on it.

This article shows you how to build that menu. It covers what dimensions belong on it, sensible defaults for each, and how to write it so partners actually read it. Just as important, it shows how to run the exceptions lane for the partner who genuinely cannot comply. It is part of our B2B Partner Exchange series and builds directly on the patterns and register from running partner exchange as a program. The museum stays open until the last exhibit is migrated. This is how you start closing it.

Why a Short Menu Beats Infinite Flexibility

The argument for standards is arithmetic before it is philosophy. Suppose you have thirty partners and no standards. Realistically you end up with three or four protocols, five or six authentication arrangements, a dozen naming schemes, and assorted one-off quirks. Every one of those variations multiplies through everything you do:

• Operations. Troubleshooting a failed transfer starts with "how does this one work again?" — a question that costs twenty minutes before diagnosis even begins. With a menu, the answer is one of a handful of known shapes.
• Security. Each variant is its own attack surface to review, harden, and audit. A cleartext protocol kept alive for one partner is a finding on every security review for years.
• Monitoring and automation. Alerts, freshness checks, and processing jobs are cheap to build for one convention and expensive to rebuild for twelve.
• People. A new team member can learn four patterns in a week. Thirty bespoke arrangements take a year — and until then, the veterans carry every incident.

There is also a fairness argument worth making to whoever pushes back: standards are what let you serve partners quickly. The partner who wants a fast onboarding benefits from the menu more than anyone, because selection is fast and design is slow. That is the whole premise of the onboarding runbook. Infinite flexibility does not scale kindness; it rations it to whoever shouted most recently.

One caution in the other direction: a menu with one item is not a standard, it is a wall. If your only offer is "SFTP with keys, take it or leave it," you will meet the partner who cannot take it. That partner is usually a small one, or a big inflexible one. Then the choice is losing the business relationship or improvising under pressure. The menu needs a default, a supported alternative or two, and an exceptions lane with rules. That shape absorbs reality without dissolving into it. I have seen a one-item menu lose a partner and a twelve-item menu lose every weekend. The shape in between is not a compromise, it is the design.

The Dimensions That Belong on the Menu

Keep the menu to the dimensions that shape your infrastructure and security posture. Six cover almost everything:

1. Protocols — which transfer protocols you offer, and which you refuse.
2. Authentication — how partner accounts prove who they are.
3. Connection pattern — the standard shapes from your program: partner pushes to you, partner pulls from you, you push, you pull.
4. File naming — the convention every exchanged file follows.
5. Encryption — what protects data in transit (always) and when payloads are additionally encrypted at rest.
6. Timing conventions — how schedules, cutoffs, and timezones are stated, so every flow's promises are written the same way.

Deliberately off the menu: per-flow file formats — column layouts, record structures, acknowledgment semantics. Those belong in the interface contract agreed per flow, a subject with its own series in files as integration glue. The standards menu says how files travel and what they are called; the interface contract says what is inside them. Combine them and you get a document nobody finishes, including its author.

A Worked Standards Menu

Here is a complete menu of the kind a mid-sized program runs. Treat it as a starting point to edit, not a prescription — the right menu is the one your team can operate and your actual partners can meet.

Three of these rows deserve a word on the reasoning, because partners will ask:

• Why SFTP as the default? One port, encryption always on, key-based authentication built in, and firewall behavior that is easy to explain to a partner's network team. The full comparison — including where FTPS is the better fit, typically shops with existing TLS tooling — is in choosing a protocol for partner exchange. And plain FTP is off the menu for the reasons laid out in why retire FTP: credentials and data cross the network readable by anyone in the path.
• Why keys as the default, passwords as the fallback? Keys survive at scale — no resets, no expiry emergencies, clean rotation. Passwords remain the honest fallback for partners whose tooling cannot manage a key pair. The portfolio-level reasoning lives in credentials and security across many partners.
• Why OpenPGP only for sensitive classes? Payload encryption protects a file even while parked on disk, at the price of key management on both sides. Reserve it for data that warrants the ceremony — payroll, health, payment files — as covered in encrypt-before-send workflows.

The timing row looks like the least technical of the six, and it prevents the most arguments. "Daily by 06:00, named timezone, files after cutoff processed next cycle" is a sentence both sides can test; "sent every morning" is a future dispute. Standardizing the way expectations are written is what makes them measurable later. Every flow gets a window, a cutoff, and a timezone. That is the entire subject of SLAs and expectations for partner file exchange.

How do you pick your defaults, rather than copying this table? Look at three populations honestly. Your team: default to what you can operate and debug at three in the morning, not what impressed you in an evaluation. Your server: the menu can only offer what your infrastructure genuinely supports today. And your actual partners: skim the register (or your last dozen onboardings) and note what their side could realistically do. A menu that eighty percent of your real partner population can meet without an exception is calibrated. One that half of them cannot meet is a wish. When two options tie on those tests, pick the one that fails loudest, because quiet failure is the expensive kind in partner exchange. Loud failures get tickets. Quiet ones get discovered at month end.

Make the Server Enforce the Menu

A standard that lives only in a document is a suggestion. The menu becomes real when your infrastructure offers exactly what the menu offers and nothing else. Then compliance is not a partner's promise, it is a property of the system. A document can be argued with; a closed port cannot.

Most of the menu enforces itself through server configuration. On a server like Sysax Multi Server, the protocol row is enforced by which services you enable for partner use. The authentication row is enforced by per-account settings. Each partner gets a built-in or Windows/Active Directory account, with public-key authentication where the menu says keys. The pattern row is enforced by per-account permissions that confine each partner to its own folder tree. The password-plus-allowlist option is enforced by IP allow rules on the account. A partner physically cannot pick an off-menu option, which is precisely the point.

Naming is the one row the server cannot fully police, because partners generate the names. Enforce it one step downstream. The collection job that sweeps each partner's inbound folder moves conforming files onward and routes everything else to a quarantine folder with a notification. So a misnamed file becomes a bounce-back conversation during business hours instead of a silent processing failure at night. The OpenPGP row, likewise, is enforced in the pipeline. In Sysax FTP Automation, the scheduled partner job can decrypt inbound OpenPGP files and encrypt outbound ones as a step of the transfer itself. So the standard runs on a schedule rather than on memory. Schedules do not forget. Memory, in my experience, does little else.

Writing Standards Partners Actually Read

The standards document is a partner-facing artifact. It travels in the onboarding packet, beside the partner connection guide. So write it for a partner's junior administrator, not for your auditor:

• One page of rules, then appendices. The menu table fits on a page. Host key fingerprints, example files, and allowlist instructions go behind it.
• An example for every rule. "Files must follow the naming convention" invites interpretation; ALPINE_orders_YYYYMMDD.csv ends it. Show a correct file name, a correct folder path, a correct schedule statement.
• State what happens on violation. Nonconforming names go to quarantine and generate a notice; connections from unlisted addresses are refused; late files are processed next cycle. Partners respect consequences they were told about and resent ones they discover.
• Explain the whys in one sentence each. "We require encrypted transport because credentials and business data cross the public internet" converts more partners than a bare mandate.
• Keep a change history and version marker. When the menu changes, partners should be able to see what changed and when their flows are affected — a discipline that pays off in the evolution section below.

The Exceptions Lane

Some partner will not fit the menu. Their ancient ERP only speaks FTPS with passwords; their security policy forbids installing key management; their volume justifies none of your ceremony. The exceptions lane is how you say yes without dissolving the standard. The alternative to a managed exceptions lane is not "no exceptions." It is unmanaged ones granted verbally and remembered by nobody. Verbal exceptions have excellent uptime and no documentation.

An exception in a healthy program is a small record with five mandatory fields:

• What rule is being excepted, for whom — one partner, one rule. An exception never quietly covers a category.
• Why — the concrete constraint, in one or two sentences, so future readers can tell whether it still holds.
• Compensating controls — what narrows the added risk: a tighter IP allowlist, reduced permissions, payload encryption layered on, extra monitoring.
• An approver — the program owner by name. Exceptions are decisions, and decisions have deciders.
• A review date — the date this exception is re-argued or expires. An exception without a review date is not an exception; it is the new standard, granted by fatigue.

A worked example, in the shape it would appear in your register: Cedar Freight — FTPS with password instead of SFTP with key, because their dispatch system's vendor supports nothing else. Compensating controls: source IP allowlist restricted to their two egress addresses, account confined to its own tree, password meeting policy and rotated on schedule. Approved by the program owner; review at contract renewal. Visible, priced, temporary — the three properties that separate an exceptions lane from a slow-motion collapse of the menu. If your organization runs a formal policy exceptions process already, plug into it rather than inventing a parallel one; the general machinery is described in the exceptions process.

Two rules keep the lane honest. First, some rows have no lane: encrypted transport is not negotiable at any volume, for any partner, because a single cleartext flow undoes the security story of the whole estate. Second, watch the lane's size. A handful of dated, shrinking exceptions is a program absorbing reality. A growing pile of them means the menu itself is wrong — too narrow, or defaulting to something your actual partner population cannot meet. The lane is your feedback channel as much as your safety valve. (For the partner who could comply but refuses, see the escalation ladder in credentials and security across many partners.)

Acme learned the review-date rule from a single missing cell. During a rush onboarding they granted a small supplier FTPS with a password "for one quarter" and wrote everything down except when the quarter ended. Three years on, a security review asked why four partners authenticated with passwords. The answer turned out to be that the first exception had been copied as the template for the next three. Nobody had decided anything; the standard had been amended by paste. Every exception got a review date that month, and the four were re-argued. Two moved to keys, and two kept passwords with the compensating controls they should have had from the start. The line they added to the top of the standards document was short: an exception without an expiry is a standard with worse handwriting.

Evolving the Menu Without Breaking Partners

The menu is a living document, and both kinds of change need choreography:

• Adding an option is the easy direction. Trial it with one willing partner first, run it through a full cycle including an incident or two, and only then print it on the menu. An option becomes a commitment the moment a partner can pick it. Resist adding options to serve a single partner; that is what the exceptions lane is for.
• Removing an option is a migration, and it deserves migration discipline. Grandfather existing users of the option with a stated deadline. Contact each one with what is changing and why, and offer the replacement path with concrete instructions. Sequence the stragglers, and only then switch the option off. The communication playbook — notice periods, test windows, the partner who never answers — is exactly the one in partner communications for an FTP retirement. It generalizes to any option you retire.

Announce changes through the same channel every time — the contacts recorded in your register — and give notice measured in months for anything requiring partner-side work. Your register makes the blast radius knowable in advance. Filter on the option being retired and you have the exact list of affected partners. That is the difference between a managed change and a surprise outage with apologies. Apologies scale worse than filters.

A Menu Is a Kindness

Technical standards for partner exchange are not bureaucracy. They are the reason partner forty onboards in days, incidents start from known shapes, and security reviews end without findings. Build the menu on six dimensions — protocol, authentication, pattern, naming, encryption, timing — with a default and a supported alternative for each. Enforce it in server configuration rather than in memos. Run one visible exceptions lane with expiry dates. Evolve it with migration discipline.

From here, see the menu in action during partner onboarding, where standards turn design into selection. Go deeper on the row with the highest stakes in credentials and security across many partners. The program framing that holds it all together is in running partner exchange as a program.

Frequently Asked Questions