By Yair Knijn · October 7, 2025

The partner mandated AS2 with signed MDNs and your stack only does SFTP

An ops manager standardizes on one protocol to keep the estate clean. Usually it's SFTP: every partner understands a folder, the team already runs the keys, and one transport is easier to watch than three. That clean estate holds right up until a large customer sends an onboarding packet that reads AS2, encrypted payloads, signed MDN required.

Single-protocol standardization assumes you get to pick. You don't. The partner with the bigger volume and the longer contract picks, and they wrote that requirement into a connectivity spec long before anyone on their side spoke to you.

Why partners mandate a protocol and won't budge

Large trading partners don't run a protocol per supplier. They run a connectivity standard, certified once and reused across hundreds of relationships. Asking them to bend it for one new vendor triggers a security review, a change request, and a queue you join at the back of. Retail, automotive, and pharma supply chains land on AS2 because they need proof of receipt that survives a dispute, not because anyone enjoys managing certificates.

So a packet that says AS2 is not a preference you talk down to "we'll SFTP you the same files." It's a control their auditors already signed off on. Speak it or you don't onboard.

What a signed MDN proves that SFTP cannot

SFTP moves a file and closes the connection. Nothing about that leaves a signed, portable artifact stating this exact payload arrived intact at this time. AS2, defined in RFC 4130, produces precisely that. The receiver returns a Message Disposition Notification, and a signed MDN carries a Message Integrity Check computed over the payload. The original sender then verifies the MIC in the returned MDN against the value it recorded on send.

That match is the entire point. RFC 4130 calls it non-repudiation of receipt, and it separates "our logs show we uploaded it" from a counter-signed receipt the partner can't later disown. A clean SFTP transfer log is your word. A signed MDN is theirs.

The onboarding delay when your stack can't speak their protocol

The timeline slips in a predictable way. The deal closes, the partner's EDI team sends the spec, and your platform can neither generate AS2 nor sign an MDN. Now every option is a bad one:

• Bolt on a separate AS2 gateway, which means new infrastructure, a second audit surface, and a certificate exchange that runs on the partner's calendar rather than yours.
• Ask the partner to accept SFTP instead, which restarts their internal review and usually comes back declined.
• Route files through a broker, which adds a hop, a recurring cost, and a third party in your chain of custody for regulated data.

Each of those tends to push go-live out by a quarter. Revenue you already booked sits idle while certificates get exchanged and a test MDN finally comes back signed and verifying.

Why protocol breadth is a sales lever, not a checkbox

Breadth isn't a line item for the technical eval. It's what keeps a signed contract from decaying into a stalled implementation. The ops manager who standardized on one transport optimized for the estate in front of them and quietly created a deal-timeline risk for every future partner who arrives with a different requirement. The partner you haven't signed yet is the one whose spec you can't read.

The move is to stop treating transport as a platform-wide decision and treat it as a per-partner one. In xEvolve, AS2 and SFTP live in the same Environment behind one audit trail, so a partner mandating signed MDNs becomes a configuration rather than a procurement event. Check the supported protocols before your next onboarding packet decides this for you.