Sharing private keys - where all parties who have the one, single key can both decrypt as well as encrypt - is certainly not safe the way it's done at most companies (i.e. with a weak password, used over and over for different files, vendors, and clients, and usually sent via unencrypted email).
The two major other ways are:
Encrypted transport, i.e. data in motion encryption - HTTPS, FTPS, and SFTP all fit into this model.
Public key encryption, in this context data at rest encryption, i.e. GPG - or an easily installable package including a GUI, such as GPG4Win, which has two keys for each file recipient, be it a company or Person B themselves.
The public key, which can be shared with the entire world(!) perfectly safely.
The private key, which is held by the recipient only, protected by a passphrase only that recipient (or their automated software) knows.
Anyone and everyone encrypting and sending TO Person B needs only Person B's public key.
Person B only needs Person B's private key to decrypt, no matter how many people are sending them files.
Now, if Person A is sending files to Persons B, C, D, and E, then Person A needs four public keys - one for each recipient.
There are a variety of other options, some required in regulated contexts in the United States, but those aren't critical to most users.
Note that the ideal case is to use both, plus GPG signatures (a way of validating that Person A's private key was in the hands of who really sent it, presumed to be Person A themselves)
Note also that a plain FTP username/password is 100% visible to anyone and everyone between Person A's computer and Person B's computer, since it's sent in cleartext over the wire.
may affect the speed of the file transfer
- would it be so hard to test? Most ssh servers/clients can compress data - not true of FTP.