Create concept how we can support TransferWise as payment method

[alfsbs]

@ManfredKarrer commented on Mon Jan 22 2018

TransferWise seems to be used by some Bisq users but often leads to arbitration because the sending bank account of TransferWise is not as defined by the user (he cannot know it in advance).
It would require a concept how we can support TransferWise without breaking our security mechanism and without adding too much dev efffort.
Anyone how is capable and willing to work on that can earn BSQ in context of our DAO compensation requests.

See also: https://bisq.community/t/transferwise-borderless-account-and-outgoing-transfers-from-different-account/2224/9

[nothingmuch]

I can't tell if it's for all transfer methods, but trasnferwise does have an optional reference field with maxlength="16" which is fairly clearly laid out, which could be used to identify:

This seems like the same authentication model that cash app payment method provides (based on the USD demo video), and like a normal bank account when receiving (for the main currencies you just have your own bank details)

The simplest thing I can think of resolving the original issue is to have a send only transferwise payment account with dummy details and a receive only account with the details they provide, as just regular bank transfer account (they support USD, AUD, EUR and GBP).

What is the reasoning behind knowing the sending account's details? is that to limit the possibility of chargebacks? If so, I think that there's an unavoidable composition problem, i.e. any normal bank account can receive money from either known bank accounts, or these virtual ones interchangeable ones, and transferwise is a specific instance of the virtual kind. If that carries additional counterparty risk, a seller of bitcoin with e.g. a local bank account account would need to indicate acceptable classes of sending accounts. This seems like a nightmare of a change though, adding a degree of polymorphism between the different kinds of bank accounts.

Interestingly, it can also leave the recipient account details unspecified, taking an email address instead, which has some potentially positive implications for privacy. As far as I can tell you can pay with a whole bunch of methods too, so this looks pretty flexible.

This suggests another alternative, which is multiple distinct subtypes of transferwise accounts, e.g. one like cash app, one like a receive only bank transfer account, and another kind of bank transfer account that does not care about the counterparty's details (so e.g. replicating SEPA, faster payments, and all the various types into a sender particular and sender agnostic variant).

TBH all of these ideas seem kind of clunky to me, but I spent some time poking through their website and I wanted to document the details even though I don't think I've offered any constructive suggestions.

Edit to add: this seems to me like its related to the redundancy between e.g. faster payments and cash deposits accounts w/ same info

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ripcurlx]

Might be still useful to add in the future.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.