Designing Secure B2B File Exchange — Architecture Guide for Engineers

Designing Secure B2B File Exchange

Secure B2B file exchange is a design problem as much as it is a configuration problem. The decisions you make early — protocol, trust model, credential strategy — determine how much operational overhead you will carry for the lifetime of the exchange.

Start with what the partner requires

The protocol selection for any B2B exchange should start from partner requirements, not preference.

does the partner require AS2? If yes, you need AS2.
does the partner provide SFTP access? Start there.
does the partner require FTPS with explicit TLS? Configure that.

Do not choose a protocol for technical elegance if the partner requires something else.

Design the trust model explicitly

Before writing any configuration, answer these questions:

For SFTP:

do you have the partner’s SSH host fingerprint from a trusted channel?
is the partner’s SSH host key known to change (some hosting providers rotate keys)?

For FTPS:

does the partner have a CA-signed certificate or a self-signed one?
do you have the CA cert or the server cert itself?

For AS2:

what certificates does the partner use for signing, encryption, and HTTPS?
which algorithms do they require (sha256/aes256 is typical)?
sync or async MDN?

For any protocol:

where will partner credentials be stored?
who has access to the configuration and keys?

Define the idempotency behavior

Before going live, decide what should happen if the flow runs twice on the same source directory.

For outbound delivery:

can the partner receive the same file twice without business impact?
if not, use idempotency_mode: hash

For inbound pickup:

is the remote file stable once written? Use require_stable_remote if not.
should downloaded files be deleted from the remote? Use delete_remote_after_decrypt or delete_after_download.

Design the cleanup lifecycle

Files move through stages: source, in-flight, landed. Design what happens at each stage:

source files → transfer → landed files
              ↓
         encrypted intermediates (if PGP)
              ↓
         dead-letter (on failure)

Decide:

which files are deleted after successful processing
where failed files go (dead-letter path)
how long landed files are retained
whether staging directories are cleaned routinely

Plan for failure from the start

Reliable B2B exchange assumes failures will happen. Design for:

Retries: SFTP retry on transient connectivity issues
Dead-letter: where failed files go
Idempotency: safe reprocess behavior
Notifications: who is alerted and how quickly
Investigation path: how operators diagnose “the file didn’t arrive”

Audit evidence requirements

For regulated exchange (finance, healthcare, supply chain), determine:

what audit retention period is required
whether tamper evidence is needed
whether records must be in an external system

Make these decisions before go-live. Retrofitting audit requirements after the fact is harder than building them in from the start.

Validate before each partner goes live

Before enabling automated schedules for any partner:

validate configuration: xferity validate
run diagnostics: xferity diag <flow>
run once manually: xferity run <flow>
confirm the audit trace: xferity trace <file>
review the Partner Crypto Policy in the UI