Onboarding a file-transfer partner is slow because someone on your side provisions access on the partner’s behalf, using details only the partner has. Every new counterparty becomes a ticket, and every ticket waits on a different team. Keep SFTP. Stop standing in the middle: invite the partner to a channel and let them set up their own end.
Why does SFTP partner onboarding take weeks?
A new counterparty wants to send you files: nightly positions, a claims feed, a payment file. Here is what happens at most banks and insurers.
Someone raises a ticket. Someone else creates a directory for the new partner. Networking adds their egress IPs to an allowlist. The partner emails a public key, or asks for one, and now a key is sitting in a mail thread. Security wants PGP on the payload, so there is a second key exchange. A fourth person writes the runbook entry. Two weeks later the partner connects from an IP nobody mentioned, and the thread reopens.
None of those steps is hard. Each is ten minutes of work, and together they take weeks of elapsed time, because each one queues behind a different team’s backlog and none of those teams owns the outcome. The cause is structural: a human on your side assembles access for someone else, from details that someone else has to send in. So the people who run file transfer spend their week as a help desk for other companies’ connectivity.
SFTP is not the problem
SFTP is the quiet backbone of financial services, and it is not going anywhere. Payment files, lockbox, positive pay, NACHA batches, claims, bordereaux and regulatory extracts all move over it. Key-based login, an IP allowlist and an encrypted payload are a strong control set, and your counterparty’s integration team already knows how to script against it.
So “just build an API” is rarely the answer. Your partner does not want to write a client for your bespoke endpoint and push it through their change board. They want to drop a file on a schedule, the way they already do for every other institution they deal with. Keep the protocol. Get rid of the ticket queue wrapped around it.
The onboarding tax, itemised
The cost is not the licence. It is the per-partner work that repeats forever, and the elapsed time it buys.
| Step | Sits with | Why it waits |
|---|---|---|
| Create the account and home directory | File transfer team | Queued behind that team's other tickets |
| Collect the partner's source IPs | Whoever is emailing the partner | The partner has to ask their own network team |
| Add the allowlist entries | Network or security | A change window, sometimes a CAB |
| Exchange SSH public keys | Both sides, by email | A round trip per correction, and a key in a mail thread |
| Set up PGP keys for the payload | Security | A second, separate key exchange |
| Agree the folder layout and file naming | Application team | A conversation nobody scheduled |
| Write it down | Whoever remembers | Usually last, usually thin |
Then it happens again. The partner rotates a key. They move data centres and their IPs change. Their integration lead leaves and the replacement cannot find the credentials. A second business unit wants its own feed. None of these is a new partner, and each costs most of the sequence a second time.
Two more costs show up in an audit rather than a backlog. The evidence is scattered: who had access to that feed in March, and when their key last changed, lives across a ticketing system, a mail thread and someone’s memory. And the friction gets defended. Where four teams check each other, it is easy to argue that the checking is the control. It is a slow substitute for one, and a key pasted into an email thread is not a stronger control than a key the partner installed themselves and you never saw.
If you want one number for your own organisation, measure calendar days from “partner agrees to send us a file” to “first file lands”. Most teams have never measured it. That is usually the finding.
Invite, don’t provision: self-service partner onboarding
In DocEvent you create a channel: one stream of files with one destination, such as the claims feed or the settlement extract. You decide once where its files are delivered, then you invite the partner by email or DocEvent username. Here is what the partner does next, without you.
They create their own DocEvent account, accept the invitation and add their own sending endpoint, choosing how they want to send:
- SFTP or FTPS to a DocEvent-hosted upload server they set up themselves, with their own usernames, passwords and SSH keys. In banking and insurance, where every counterparty has a scheduler, this is the common case.
- HTTPS: an upload URL and API key, for a system that would rather POST the file. See sending files with an HTTP request.
- Email, for a person at a small broker or regional carrier who sends an attachment and is never going to automate anything.
- Their own server or bucket, which DocEvent polls on a schedule, for a partner who would rather publish files than push them.
This changes the economics. The protocol argument, the one that eats a week of meetings while their integration team explains what they can support, stops being your problem, because you are no longer choosing for them. One partner scripts SFTP, another POSTs over HTTPS, a third emails an attachment, and every file arrives in the right channel and is delivered to the same place.
What you did not do matters as much. You did not collect their IPs by email, generate a key and send it to them, wait for a network change window, or write up a folder layout agreed over the phone. You created a channel and sent an invitation. The partner’s connectivity became the partner’s job, which is the only place it ever works well, because they are the only ones who know their own network.
Is self-service onboarding safe for banks and insurers?
This is the objection every risk function raises, and it deserves a straight answer: letting a partner set up their own end is not letting them loose. Access is still yours to grant and to take away. What goes away is the ticket.
- You decide who joins. Only someone you invite can send into a channel, and each member carries their own send and receive permissions.
- Removing access is one action. Remove a partner from the channel and their endpoints are deleted with them. No hunting for the account, the key and the allowlist entry across three systems.
- Credentials never pass through you. The partner sets their own passwords and installs their own SSH keys, and can lock their upload server down to their own IP addresses. Nothing travels through an inbox, and you never hold their private key.
- One channel per counterparty. Give each partner its own channel into the shared destination, and each one sees only its own files.
- Every file is traceable. The routing log follows each file from the moment it arrives to its delivery into your storage, with a per-file journey view, in one place rather than a ticket history.
- Failed deliveries are recoverable. If a delivery into your storage fails, say during a permissions change, the file parks in Stuck files and you reprocess it in one click instead of asking the partner to send it again.
There is a security argument here as well as a speed one. The usual process has keys travelling through inboxes and access details living in tickets. Self-service onboarding takes both out of circulation.
The files are delivered into your bucket
For a regulated buyer this matters more than any feature above. A channel delivers into storage you already own: an Amazon S3 bucket or any S3-compatible one (Cloudflare R2, Wasabi, MinIO, Backblaze B2), Azure Blob Storage, or Google Cloud Storage. Not a vendor’s storage tier you rent back and have to migrate off later.
That has three consequences worth spelling out for whoever reviews this internally. Your residency and retention rules already apply, because the bucket is in your account, in the region you chose, under the lifecycle and encryption policies your security team already signed off. Your existing tooling already sees the files: the data platform, the backup, the DLP scanner keep working, because only the way files arrive changed. And arrival can start work. The bucket’s own event notifications can trigger AWS Lambda, a Step Functions workflow via EventBridge, or Azure Functions via Event Grid, so the file that lands at 2:14am starts its validation immediately instead of waiting for a poller on a cron.
If the relationship ever ends, you keep everything, because it was always in your bucket.
How does this compare with AWS Transfer Family or Azure SFTP?
Compare on the per-partner work, not the sticker price. Every option below can move a file; they differ in how much of your week each new partner takes.
| Option | What you operate | Onboarding a partner |
|---|---|---|
| Your own SFTP server | The host, OpenSSH, patching, jails, backups, the DMZ | You create every account, key and allowlist entry |
| AWS Transfer Family | AWS runs the endpoint; you manage users, keys and IAM | You create every user, by console, API or a custom identity provider |
| Azure Blob SFTP | Azure runs the endpoint; you manage local users | You create every local user on the storage account |
| MFT suites | A product, often a server, often an upgrade project | You create every partner in the admin console |
| DocEvent Channels | Nothing - delivery goes into your own bucket | You send an invitation; the partner sets up their own end |
The managed cloud endpoints also bill by the hour whether or not a byte moves. AWS Transfer Family charges US$0.30 per enabled protocol per hour plus US$0.04 per gigabyte each way, about US$219 a month before any data moves. SFTP on Azure Blob Storage charges US$0.30 an hour while it is enabled, about US$216 a month, and Microsoft’s own documentation suggests disabling it between transfers.
More importantly, none of them changes who does the work. They give you an endpoint; you still create the users, hold the keys and allowlist the addresses on your partners’ behalf, and the ticket queue is untouched. That is the gap worth pricing: not dollars per hour, but who does the work every time a counterparty shows up. Channels are free while in preview, then per user, with operations included in each plan.
Start with one partner
Do not migrate anything. Pick the next partner due to be onboarded, the one whose ticket would otherwise open next week, and run them through a channel instead. Create the channel, point it at a bucket you already own, and send the invitation. Then measure one number: days from invitation to first file, against the last partner you onboarded the old way.
If it is not dramatically shorter, nothing is lost and the ticket queue is where you left it. If it is, you have found out what the onboarding tax was costing you, and you have a second partner to try it on. And if your first partner needs something the channel does not do yet, tell us - that is exactly the conversation we want to have.
References
- AWS Transfer Family pricing - US$0.30 per hour per enabled protocol and US$0.04 per gigabyte uploaded or downloaded, US East (N. Virginia).
- SSH File Transfer Protocol (SFTP) support for Azure Blob Storage - enabling SFTP has an hourly cost, and Microsoft recommends enabling it only while transferring; the US$0.30 hourly rate is from Microsoft’s published pricing, as compared on our Azure SFTP page.