Most payment vendors are on SFTP at this point. Very few still use only FTPS. But then they do silly things with SFTP, like requiring both a password and the ssh key.
In the past I've done the same things, as some have mentioned already, as a form of two-factor authentication.
There were a few reasons for this that made a lot of sense:
(1) Private keys were being stored haphazardly -- people were not protecting them with passwords and occasionally they ended up on network drives. It's possible to enforce password policies for the hosts in question, but not possible to enforce 'how you protect/handle your private key' centrally[0].
(2) The second only applied to an environment I managed in the past, but we had many Linux hosts that were AD domain joined and authentication occurred directly via AD credentials (no local account authentication). The servers were configured to allow password-only login when the user had never connected to the host before. Once the user had connected the first time, the host would receive the public key for that user and future logins would only require the key[0].
[0] ... that latter part they failed to ever get working properly. It always prompted for both. Based on my conversations with the team managing the servers, there was zero priority assigned to fixing that problem -- they were resentful of the fact that the Linux (Debian, incidentally) hosts were domain joined and allowed domain authentication and they had a poor opinion of the security of using AD user accounts for authentication (nobody would make an argument other than Micro == small, soft == not hard or some other snark like that -- we had some BOFH over there).
That doesn't sound that unreasonable. Both satisfy the "something you know" and "something you have" portions of multi-factor authentication (respectively).
Considering that this is money on the line, the idea of banks actually taking security seriously is actually refreshing. Too bad they don't seem to apply those standards to their customers.
If you can duplicate it, then it's something you know, not something you have. Everything you know in sum-total is one meta-passphrase, even if it's a combination of key-files and other data.
The 'something you have' would have to be a specific hardware token (E.G. that VPN tunnel device someone else mentioned that is a black box you aren't allowed to open). Tamper resistance and physical security locks to ensure that connections /must/ route through a given location would be enough.
"If you can duplicate it, then it's something you know, not something you have."
By this logic, a typical door key is "something you know" rather than "something you have" (never mind the uselessness of memorizing one's key shape when it comes to actually unlocking a door).
Unless you're memorizing your private SSH keys (in which case I applaud your superior intellect), it's absurd to claim that said keys fall into "something you know".
It's a key pair, for SSH keys, which is what SFTP uses to tunnel the FTP protocol. You cannot derive the private key from the public key. So no, you cannot duplicate someone's private key unless you have access to their machine. In which case you could just install a keylogger.
Hardware tokens are vulnerable too, by your own admission. A 6 digit pin created by a token is still "something you know" even if it's only good for a couple of minutes.
