Add SWIFT (int. wire transfer) as payment method

[ManfredKarrer]

I am wondering if we should add international wire transfer (SWIFT).

There are some issues thought:

• Banking fees are rather high (50-100 USD) which makes that very expensive if used with low trade limits (about 400 USD atm for new accounts).
• Fees are not clearly determined and receiver will also get charged by a fee. Furthermore some banks allow to define the fee model. There are 3 options: 'Sender pays', 'receiver pays' or fee is 'shared'. I think default is shared but users who manage to set that to 'receiver pay fee' can save much money on cost of the peer.
• It seems that the receivers address is required which adds some privacy and security risks to the traders. But not sure if the address is verified. Many users change real address when moving house and do not update address at bank (often the bank webpage does not support that anyway).
• Transfer takes 3-5 working days but can take even longer
• It is not very clear to me how to find out if an intermediary bank is needed. I assume the banks figure it out themself and add on demand intermediary banks (and increase total fees by that) or it need to be defined by the users, but that will prob. not work as you don't know in advance the combination of the sellers and buyers banks.
• If the bank cannot complete the transfer more undfined costs may apply to the sender.

So all in all it seems like a can of worms and thats why we never added it but I am still wondering if we should offer it and make it very clear to the user which risks and issues are connected to it. There are countries with no Bisq market developed yet and that payment method could help to connect those isolated users to trade between them. Also in such countries they pay a huge premium anyway on LBTC or other exchanges, so the high fees might be not an issue for them. It could also help to bootstrap a national tranfer market once there are a few traders using Bisq there.

I think chargeback risk is very low, so that is a good part.

We would need to use a high trade limit otherwise the costs are way too high (25% of the trade if the costs are 100 USD for a 400 USD tx). We could allow 0.25 BTC for new accounts (about 1600 USD) then the 100 USD fee would be "only" 6%. Once the account has 2 months then its 1 BTC and then the fee with 1.5% is actaully pretty reasonable.

Another problem is how to deal with the fee mode. There is an incentive that the sender tries to let the receiver pay the fee if his bank offers that option. So maybe the best would be that we use that as the default case. The extra costs for the fee for the Fiat receiver can be priced in the offer price. There can be though then cases where the sender cannot select that and then the seller has the disadvantage.

Arbitration with the fee issues migth become an issue. But I think if we use the model that the reciver pays all fees and communicate it clearly that fees are not determined it should be ok. User has to be aware of an extra risk factor here. A sender who pays more fee because his bank does not allow selection of the model or is instranparent with fees has to complain at his bank.

@alfsbs What do you think?

[sqrrm]

It would be nice for certain cases to allow this but it's probably going to increase arbitration cases a bit, not sure that would be worth it. Transfers can get stuck for weeks sometimes and sometimes just returned (instead of being delivered) for no good reason. Perhaps worth trying and reconsider if arbitration cases increase due to this. If the charge back risk is indeed lower (I believe it is, but can't say with authority) then it makes sense to increase the limits and it would open up for more international transactions. It could always be removed if the increase in complicated arbitration is too much.

[cbeams]

I don't have a problem with trying this, but I do think it'll be problematic with regard to arbitration. Whenever I do a wire, it's $40 and a series of back-and-forth forms and conversations over email and phone with my bank. I'm sure other institutions are more efficient than mine, but I'm sure others are as bad or worse. I can see trading windows getting exceeded easily, unless we make them quite long.

I also have no idea what the demand for this is or could be. We should focus on getting the word out better about new payment options. I think people just don't know what's available.

@alfsbs, is any data available from LBTC, et al on whether SWIFT is a popular payment method?

[ManfredKarrer]

I think there is rough consensus that we want to add that payment method. I will ask for developers to implement it and offer a bounty of 500 BSQ.

[fedegrc]

You can send money internationally to a SWIFT/BIC account with Xoom (transaction fee USD ~5).

[ManfredKarrer]

@fedegrc Xoom is a Paypal company. Do ypou know their chargeback policy? If it is similar to Paypal its not an option. oHow do they deal with the unknown receiver fees?

[ManfredKarrer]

"Xoom is a fast, simple, and secure way to send money, reload phones, and pay bills for people in over 70 countries around the world. All you need to send a transaction using Xoom is a U.S. bank account, credit card, or debit card."

So seems you need to have a bank account. It also support not all coutries but 70.

Might be interesting to investigate if it would make sense to add it a new payment method if anyone can investigate more and check chargeback risk. But that "... family and friends.." statement at https://help.xoom.com/s/article/xoom-basics?language=en_US already is a sign that chargeback policy is likely same as at Paypal, Venmo, Cashapp...

[fedegrc]

I'm not sure, but I think that transfers from a Xoom account to a bank account (SWIFT) is basically a wire transfer from Xoom to a bank.

"Three ways to send money:

1. Deposit to a bank account. Send money to almost any bank account.
2. Send cash for pickup at thousands of partner locations around the world.
3. Have cash delivered. Send money directly to your recipient’s door."

[gibechoes]

Just thinking its a hassle to have swift and national account offers open if you want to accept both. Until offers can be taken by using multiple payment methods..... I wonder if the switft payment method could be setup optionally within the current national account setup. Have a checkbox, confirming this account/bank accepts swift and then punch in details, also countries that you are willing to trade with. Just some ideas.

[ManfredKarrer]

@gibechoes Supporting multiple accounts is complex and I would only start on that if we have a dedicated developer who wil take care longterm of the payment methods. It would probably require a bigger refactorin gof the existing model to make it easier to support.

[aicbaicb]

I believe that when making payments from the EU, the only option now is "fee is shared", per Directive 2007/64/EC (now replaced by Directive EU 2015/2366). This Act enforces the SHA option (shared expenses) for transfers carried out in euros or in a currency of any EU member state.

So having "beneficiary pays" as a default won't work for Euros, Sterling, etc.

[ManfredKarrer]

Ah great thanks for the info!

[cyphersphinx86]

If this issue is still open I'd like to take a shot at it.

[ManfredKarrer]

Yes it is open. Would be great if you can take it!

[ghost]

Hm, I'll look into this. Don't let this stop you from implementing it, as it will probably take a while for me.

[user135711]

@Manfred please do add xoom as a payment method for cash pickup (I've transferred thousands on many occasions with no issues except once when they put a hold and required my id verification as sender(I sent to myself to get the exchange rate). You can't chargeback cash and they give very good exchange rates. Also, why not add remitly which has the best exchange rates on the first transfer?

[ManfredKarrer]

Can you provide all the required info? @alfsbs Are you familiar with Xoom?

[user135711]

@ManfredKarrer it's been a few years since I used Xoom so I don't remember the exact procedure but it was just like western union but cheaper and with a better exchange rate. You pay with a bank account online with a $5 fee (much more if you use a card), and the receiver picks up cash with an id on stores located pretty much everywhere. Maximum transfer is 10,000. Never used remitly but they have an even better exchange rate. Xoom also now states they can deliver cash to your home address.

[user135711]

@ManfredKarrer also walmart has a walmart2walmart cash sending system that might be worth investigating.

[user135711]

Also worldremit and RIA are two more cash pickup options that should be added.

[ManfredKarrer]

We are short on resources on payment methods. If you are specialist with those you are welcome to help us. Main work is to make sure that they suit our requirements and that we know exactly what data is needed and how they work and what are the risks. @alfsbs was doing that in the past but seems he is too busy lately with other stuff....

[user135711]

Sure, I may actually try them out over at local bitcoins and report back on how things go. I used to western union once a month and know if you transfer over $500 the teller has to fill out a form with your phone, home address, occupation and social security number. The other services I suggested are much more economical though if there are no tricks.

[ManfredKarrer]

Most important is that there is no/low chargeback risk and that arbitrator can get some tamperproof evidence in case of dispute. Some webpage with tracking number or the like would be prob. ok. We use PageSigner to get proof of the webpages content.

[dav1dpgit]

We should add international wire transfers (SWIFT) into the payment options. Some responses to all of the above: “Banking fees are rather high (50-100 USD) which makes that very expensive if used with low trade limits (about 400 USD atm for new accounts).” [DP] Banking fees are $20-30USD, and are reduced for those who have balances in the bank. Those with low trade limits should look to either aggregate with the same counterparty or not trade using this methodology, but it should not be a reason not to have the payment option. Fees are not clearly determined and receiver will also get charged by a fee. Furthermore some banks allow to define the fee model. There are 3 options: 'Sender pays', 'receiver pays' or fee is 'shared'. I think default is shared but users who manage to set that to 'receiver pay fee' can save much money on cost of the peer. [DP] Fees are clearly determined. The sending party should know their own wire transfer fees, and the receiving party should know their own wire transfer fees. It seems that the receivers address is required which adds some privacy and security risks to the traders. But not sure if the address is verified. Many users change real address when moving house and do not update address at bank (often the bank webpage does not support that anyway). [DP] Receivers’ addresses are not required, only the bank address. Transfer takes 3-5 working days but can take even longer [DP] Sometimes it takes only 1 working day, too. The majority of wires are 1-3 days. If it takes longer usually something is incorrect in the sending instructions. It is not very clear to me how to find out if an intermediary bank is needed. I assume the banks figure it out themself and add on demand intermediary banks (and increase total fees by that) or it need to be defined by the users, but that will prob. not work as you don't know in advance the combination of the sellers and buyers banks. [DP] Some banks require intermediary banks, and state so on their website. If this is a requirement we can simply build this into the payment option instructions. If the bank cannot complete the transfer more undfined costs may apply to the sender. [DP] If a bank cannot complete the transfer it is due to payment instructions being incorrect (likely). This is a case for mediation and not a reason to prevent the option from being available. So all in all it seems like a can of worms and thats why we never added it but I am still wondering if we should offer it and make it very clear to the user which risks and issues are connected to it. There are countries with no Bisq market developed yet and that payment method could help to connect those isolated users to trade between them. Also in such countries they pay a huge premium anyway on LBTC or other exchanges, so the high fees might be not an issue for them. It could also help to bootstrap a national tranfer market once there are a few traders using Bisq there. [DP] Agreed. “Can of Worms” is applicable to this and any transfer methodology. I think chargeback risk is very low, so that is a good part. We would need to use a high trade limit otherwise the costs are way too high (25% of the trade if the costs are 100 USD for a 400 USD tx). We could allow 0.25 BTC for new accounts (about 1600 USD) then the 100 USD fee would be "only" 6%. Once the account has 2 months then its 1 BTC and then the fee with 1.5% is actaully pretty reasonable. [DP] I am fine with high trade limits. Higher the better. Another problem is how to deal with the fee mode. There is an incentive that the sender tries to let the receiver pay the fee if his bank offers that option. So maybe the best would be that we use that as the default case. The extra costs for the fee for the Fiat receiver can be priced in the offer price. There can be though then cases where the sender cannot select that and then the seller has the disadvantage. [DP] Even if some banks allow for receivers to pay fees, the general SWIFT use case is the sending bank charges $20-30USD, and the receiving bank also takes a $10USD cut, sometimes. Just let each bank’s fees are borne by the bank account holder as the default (Senders and receivers anticipate their own banks’ fees.) If the sender wants to transfer all of the SWIFT fees to the other side via the wire process, explicitly say this is not standard and open to rejection of the SWIFT wire. Arbitration with the fee issues migth become an issue. But I think if we use the model that the reciver pays all fees and communicate it clearly that fees are not determined it should be ok. User has to be aware of an extra risk factor here. [DP] Disagree on this point. Please see my prior process flow comment. A sender who pays more fee because his bank does not allow selection of the model or is instranparent with fees has to complain at his bank. [DP] Yes

[dav1dpgit]

When it comes to tamperproof evidence and SWIFT it will take a number of days to clear a dispute due to bank personnel needing to be involved, but again this should not deter use of the SWIFT settlement methodology.

[dav1dpgit]

Considerations

• Domestic wires have separate bank identifiers (e.g. internal to the United States = ABA number; internal to AU = BSB), so to bypass this issue we should require the SWIFT wire option in BISQ to be INTERNATIONAL SWIFT payments only.
• This is information of the recipient to be entered by the BTC buyer/fiat sender when executing a trade settled by International SWIFT.
• SWIFT can be any major currency. Currency is established in the BISQ trade, but we should make the settlement be specific to a currency, so for now we set up the BISQ account to be currency-specific.

• The BISQ naming method will be International_SWIFT_Wire_Transfer_XXX where XXX is the three-letter currency to be used. Why would Bisq benefit from adding this payment method? Is is popular in a particular region? More convenient? More safe? BISQ benefits by having a cross-border payment methodology that allows for larger flows to happen and attracts more market makers. Most centralized exchanges accept SWIFT wires in and out; it is a standard method for settlement. Connects remote trading regions, a strength of BISQ. Who can use this payment method? Anyone with a bank that permits account holders to make international transfers are able to use this payment method. Currently there are over 11,000 banks using this in 200 countries. How easy is it to cancel a payment once it's made? This is the most important characteristic of a payment method. Chargeback is very difficult and requires bank employees to mediate and requires evidence of fraud. What information must a user provide to a counterparty to accept a payment? Please see below How can payments be verified? Examples: TLSNotary is typically used for electronic payments, and receipt scans are typically used for money orders. Payments are verified when the cash arrives in the recipients account How long do payments take? Please provide a range, as the advertised best-case scenario rarely accounts for edge cases. 1-3 days is standard and my own familiarity, but can be up to 5-7 days depending on the banks involved Does it cost anything to make a transfer using this payment method? If so, how much? Yes, the sending party will incur a fee as described in their agreement with the bank. Receiving party may also incur a (usually smaller) fee, as described in their agreement with their own bank. These are clear from the outset and usually non-transferrable. Anecdotal information mentioned an option for a sender to pass SWIFT wire fees to the recipient; in those situations the receiving party will not have received the full amount and we should make it clear that is not an option within BISQ. Fees range from USD$40-$100(Anecdotal), USD$25-30 (own experience) and all the way to $0 for certain accounts. How easy or difficult is fraud with this payment method? Very difficult to send funds one does not have.

  Required or (optional) Fields:

  [EVERYTHING MUST BE WRITTEN IN ENGLISH CHARACTERS] Receiving bank SWIFT code [11 characters] Currency [Current BISQ drop down menu should be sufficient] Country of receiving bank [Current BISQ drop down menu should be sufficient] Name of receiving bank [34 characters] Address of receiving bank [Two lines of 34 characters, second line optional] Branch of receiving bank (optional) [34 characters] Intermediary bank SWIFT (optional) [11 characters] Intermediary bank country (optional) [Current drop down menu should be sufficient] Intermediary bank address (optional) [Two lines of 34 characters, second line optional] Beneficiary (person/recipient) name [34 characters] Beneficiary (person/recipient) address (optional) [Two lines of 34 characters, second line optional] Beneficiary (person/recipient) city (optional) [34 characters] Beneficiary (person/recipient) country (should equal the country of the receiving bank) Beneficiary (person/recipient) phone (optional) [20 characters] Beneficiary (person/recipient) account number [40 characters] Special Instructions (optional) [3 lines of 35 characters limit]

[dav1dpgit]

BISQ_SWIFT_Layout.pdf My thoughts on how the layout would be for the Account Setup of SWIFT payments.

[pazza83]

Hi just picking this up from #4757

It seems that the principle of adding SWIFT is something that has been decided upon but not yet implemented.

Just commenting on @dav1dpgit's excellent analysis and points with the aim to reach a consensus.

Everything looks good to me barring the potential concern I have with regards potential charge back risk introduced with the 'Stop and recall' system introduced fairly recently (see below for more info). It would be great to know if these concerns can be allayed or mitigated by anyone that has knowledge / percipience of this.

We should add international wire transfers (SWIFT) into the payment options. Some responses to all of the above: “Banking fees are rather high (50-100 USD) which makes that very expensive if used with low trade limits (about 400 USD atm for new accounts).” [DP] Banking fees are $20-30USD, and are reduced for those who have balances in the bank. Those with low trade limits should look to either aggregate with the same counterparty or not trade using this methodology, but it should not be a reason not to have the payment option.

Agreed

Fees are not clearly determined and receiver will also get charged by a fee. Furthermore some banks allow to define the fee model. There are 3 options: 'Sender pays', 'receiver pays' or fee is 'shared'. I think default is shared but users who manage to set that to 'receiver pay fee' can save much money on cost of the peer. [DP] Fees are clearly determined. The sending party should know their own wire transfer fees, and the receiving party should know their own wire transfer fees.

Agreed to some extent. Some banks add in a fee + any bank intermediary fees (these can be unknown), however I do not think this is a reason not to add this payment method. Unknowns can be reflected in the asking price.

It seems that the receivers address is required which adds some privacy and security risks to the traders. But not sure if the address is verified. Many users change real address when moving house and do not update address at bank (often the bank webpage does not support that anyway). [DP] Receivers’ addresses are not required, only the bank address.

Agreed

Transfer takes 3-5 working days but can take even longer [DP] Sometimes it takes only 1 working day, too. The majority of wires are 1-3 days. If it takes longer usually something is incorrect in the sending instructions.

Agreed

It is not very clear to me how to find out if an intermediary bank is needed. I assume the banks figure it out themself and add on demand intermediary banks (and increase total fees by that) or it need to be defined by the users, but that will prob. not work as you don't know in advance the combination of the sellers and buyers banks. [DP] Some banks require intermediary banks, and state so on their website. If this is a requirement we can simply build this into the payment option instructions.

Agreed

If the bank cannot complete the transfer more undfined costs may apply to the sender. [DP] If a bank cannot complete the transfer it is due to payment instructions being incorrect (likely). This is a case for mediation and not a reason to prevent the option from being available.

Agreed

So all in all it seems like a can of worms and thats why we never added it but I am still wondering if we should offer it and make it very clear to the user which risks and issues are connected to it. There are countries with no Bisq market developed yet and that payment method could help to connect those isolated users to trade between them. Also in such countries they pay a huge premium anyway on LBTC or other exchanges, so the high fees might be not an issue for them. It could also help to bootstrap a national tranfer market once there are a few traders using Bisq there. [DP] Agreed. “Can of Worms” is applicable to this and any transfer methodology.

Agreed, SWIFT will open up more international markets. Anyone in any country could trade with any currency as long as they had an account that could send / receive SWIFT payments.

I think chargeback risk is very low, so that is a good part. We would need to use a high trade limit otherwise the costs are way too high (25% of the trade if the costs are 100 USD for a 400 USD tx). We could allow 0.25 BTC for new accounts (about 1600 USD) then the 100 USD fee would be "only" 6%. Once the account has 2 months then its 1 BTC and then the fee with 1.5% is actaully pretty reasonable. [DP] I am fine with high trade limits. Higher the better.

Agreed, the highest payment method on Bisq currently is Advanced Cash with a 2 BTC limit.
I would propose account aging could be used with this as the limit:
0.5 BTC - Account age <30 days: trade limit is 25% of the maximum 
1 BTC - Account age 30-60 days: trade limit is 50% of the maximum
2 BTC - Account age >60 days: trade limit is 100% of the maximum

Another problem is how to deal with the fee mode. There is an incentive that the sender tries to let the receiver pay the fee if his bank offers that option. So maybe the best would be that we use that as the default case. The extra costs for the fee for the Fiat receiver can be priced in the offer price. There can be though then cases where the sender cannot select that and then the seller has the disadvantage. [DP] Even if some banks allow for receivers to pay fees, the general SWIFT use case is the sending bank charges $20-30USD, and the receiving bank also takes a $10USD cut, sometimes. Just let each bank’s fees are borne by the bank account holder as the default (Senders and receivers anticipate their own banks’ fees.) If the sender wants to transfer all of the SWIFT fees to the other side via the wire process, explicitly say this is not standard and open to rejection of the SWIFT wire.

Agreed, choosing the default fee split method is most simple. Both users will be aware of any fees. The most important thing that the fee split is defined in the trade protocol. This can be clearly defined as slit fees. If the buyer of BTC passes all fees to seller this can be settled in mediation. Hopefully this wouldn't happen much as Bisq client / website etc would make it clear that fees are to be split.

Arbitration with the fee issues migth become an issue. But I think if we use the model that the reciver pays all fees and communicate it clearly that fees are not determined it should be ok. User has to be aware of an extra risk factor here. [DP] Disagree on this point. Please see my prior process flow comment.

Agreed

A sender who pays more fee because his bank does not allow selection of the model or is instranparent with fees has to complain at his bank. [DP] Yes

Agreed

Considerations

• Domestic wires have separate bank identifiers (e.g. internal to the United States = ABA number; internal to AU = BSB), so to bypass this issue we should require the SWIFT wire option in BISQ to be INTERNATIONAL SWIFT payments only.

Agreed

• This is information of the recipient to be entered by the BTC buyer/fiat sender when executing a trade settled by International SWIFT.

Thanks from my experience making SWIFT payments that all looks great.

• SWIFT can be any major currency. Currency is established in the BISQ trade, but we should make the settlement be specific to a currency, so for now we set up the BISQ account to be currency-specific.

Agree that settlement should match market that trade was take on. 
I disagree that SWIFT needs to be set up to be currency specific? 
We could add SWIFT as a multi-currency payment method. 
Select the currency you want to trade with. Same way that Revolut is.
That way a user can make / take multiple SWIFT offers on multiple markets. 
Let me know if I have misunderstood.

• The BISQ naming method will be International_SWIFT_Wire_Transfer_XXX where XXX is the three-letter currency to be used.

I am not sure what this refers to. If in the account section when adding a new account I think it should be:
SWIFT (International Wire Transfer)

Why would Bisq benefit from adding this payment method? Is is popular in a particular region? More convenient? More safe? BISQ benefits by having a cross-border payment methodology that allows for larger flows to happen and attracts more market makers. Most centralized exchanges accept SWIFT wires in and out; it is a standard method for settlement. Connects remote trading regions, a strength of BISQ.

Agreed

Who can use this payment method? Anyone with a bank that permits account holders to make international transfers are able to use this payment method. Currently there are over 11,000 banks using this in 200 countries.

That is a lot of potential users 👍

How easy is it to cancel a payment once it's made? This is the most important characteristic of a payment method. Chargeback is very difficult and requires bank employees to mediate and requires evidence of fraud.

Thanks, I understood chargeback risk to be low. On looking at the SWIFT website however the stop and recall service does not sound good for Bisq. It allows a user to immediately stop a payment, in case of fraud or error. It would be good to know anyone's knowledge / experience of this.

Website info: https://www.swift.com/stop-and-recall-payment-service Stop and recall and SWIFT GPI documentation: https://gofile.io/d/VV5VKy

What information must a user provide to a counterparty to accept a payment? Please see below

Thanks all looks great.

How can payments be verified? Examples: TLSNotary is typically used for electronic payments, and receipt scans are typically used for money orders. Payments are verified when the cash arrives in the recipients account

Thanks

How long do payments take? Please provide a range, as the advertised best-case scenario rarely accounts for edge cases. 1-3 days is standard and my own familiarity, but can be up to 5-7 days depending on the banks involved

Thanks, I would suggest a 7 day trading window. Some people might need to take the trade and then arrange to visit branch. Not all bank offers online SWIFT and those that do can have limits less than in branch. Additionally not all users will be familiar with SWIFT and may choose to go to branch to ensure all details are correctly entered.

Does it cost anything to make a transfer using this payment method? If so, how much? Yes, the sending party will incur a fee as described in their agreement with the bank. Receiving party may also incur a (usually smaller) fee, as described in their agreement with their own bank. These are clear from the outset and usually non-transferrable. Anecdotal information mentioned an option for a sender to pass SWIFT wire fees to the recipient; in those situations the receiving party will not have received the full amount and we should make it clear that is not an option within BISQ. Fees range from USD$40-$100(Anecdotal), USD$25-30 (own experience) and all the way to $0 for certain accounts.

Agreed

How easy or difficult is fraud with this payment method? Very difficult to send funds one does not have.

Please see above info about Stop and Recall that has raised my concerns. 
If chargeback risk can be agreed to be low I think it would be great to get SWIFT added.

[ghost]

To get an idea if there is a customer base for this:

• Perhaps ask BTC traders and see if they'd be happy using SWIFT on Bisq.
• Post an anonymous survey maybe?

IMHO: As an imaginary seller, I would not use SWIFT for transacting with people I don't know. Just because of AML/KYC hazards. This payment method gets a big thumbs down from me.

[pazza83]

@jmacxx thanks for the comments.

I will have a look at finding out if BTC traders would like to utilize SWIFT.

I agree that trades in larger fiat amounts would bring additional questions from traders banks.

I would likely not utilize SWIFT either as I think the increased fiat trade amounts would lead to problems with my bank. However, I am sure there are traders with much better banking options then myself with less strict AML/KYC regulation that would not be concerned about the larger fiat amounts. Either way, I do not think this is a reason not to add SWIFT as a payment method.

[pazza83]

Upon looking at various payment method offered by other P2P exchanges I can confirm all of them utilize SWIFT as a payment method. These include:

• Paxful
• Local Bitcoins
• Local Coin Swap
• Local Cryptos
• HodlHodl
• Agoradesk

After reading into the 'Stop and recall' system. It would appear that it only allows the sender's bank to stop the payment at any point along the transfer. To recall the payment requires the agreement of the senders bank. This reduces the risk of scammers but does not eliminate it.

Therefore, I propose an additional 2 days to be added to the trade protocol taking it up to 7 days.

I also propose that signing is used due to the risk that 'stop and recall' brings.

This would make first trades more expensive to get signed. I received a SWIFT today on a shared fee split. My bank charged me €5. Whilst this is significant percentage of the 0.01 BTC trade amount it is a small price to pay for someone that wants to utilize this payment method.

Please share your thoughts ./ comments.

[Conza88]

Definitely need this for additional liquidity. Opens access to BTC buyers from all countries with no markets. All they need is bank account.

I'm in favour of multiple payment method (multi currency). Making it easier for BTC sellers and buyers globally to easily find each other... And NOT require BTC sellers to create an offer in EVERY market (possibly 180 etc they want).

There is a tendency for some banks to convert from e.g. AUD to JPY to AUD and take a cut along the way, when they shouldn't. If you stipulate clearly DO NOT CONVERT in the description, it can help. Can get your bank to refund if catching them.

In favour of longer trade terms, 7 should be fine.

Bank fees is LOW compared to alternatives in AUD $30 per transaction. The money saved is present given access to more liquidity, thus lower premiums overall. Even for low trades, may be well worth it given % premium for those in countries with no markets.

[chimp1984]

shared fee split

I think we need to make it clear that sender has to pay the fees on his side. Otherwise it gets more complicated. Receiver banks also take fees but not from amount but as separate fees (at least my bank do that). With shared fees you never see the expected amount and you dont know how much was really sent as fees are intransparent (what else to expect from banks).

[chimp1984]

@pazza83 If we require account signing it will be very hard to bootstrap because:

1. Initially there are no signed traders
2. The Min. amount of 0.01 BTC is too low in relation to the fee (for me its usually about 80-100 USD).

Do you know how long the "Stop and recall" can be applied? We could add an extra delay at receipt confirmation so the chargeback risk gets lower.

[Conza88]

Any concerns about "minimum amounts" should be considered immaterial. Your subjective evaluation of what is "minimal" isn't the same as others. Pretty simple: don't choose to trade below that amount then.

Barring others from doing so hinders not helps. For others it actually is viable.

---

From: chimp1984 notifications@github.com Sent: Friday, November 13, 2020 7:25:02 AM To: bisq-network/bisq bisq@noreply.github.com Cc: Conza conza_@hotmail.com; Comment comment@noreply.github.com Subject: Re: [bisq-network/bisq] Add SWIFT (int. wire transfer) as payment method (#1789)

@pazza83https://github.com/pazza83 If we require account signing it will be very hard to bootstrap because:

1. Initially there are no signed traders
2. The Min. amount of 0.01 BTC is too low in relation to the fee (for me its usually about 80-100 USD).

Do you know how long the "Stop and recall" can be applied? We could add an extra delay at receipt confirmation so the chargeback risk gets lower.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/bisq-network/bisq/issues/1789#issuecomment-726350643, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMMLWYWDQHKKHUA3FCQI5QDSPRHC5ANCNFSM4F6CNY2Q.

[pazza83]

Thanks for your comments @chimp1984

@pazza83 If we require account signing it will be very hard to bootstrap because: The Min. amount of 0.01 BTC is too low in relation to the fee (for me its usually about 80-100 USD).

Bank fees of $100 are going to be restrictive even at 0.25 BTC limits. Is this how much you would pay to receive a SWIFT transfer from a user from a country you could select where the SWIFT fees where shared? This option would be available when you were choosing which offer to take to sign your account.

I would say anyone with bank fees of ~$100 would be looking for alternatives to SWIFT. Most fees are much lower than that from what I have seen average $20-30 in US and less than 20€ in Europe. Whilst expensive for a first trade I think it is a small amount to become signed to access larger amounts. This in turn reduces risk of 'Stop and Recall' being utilized.

Do you know how long the "Stop and recall" can be applied? We could add an extra delay at receipt confirmation so the chargeback risk gets lower. The 'Stop' can be applied at any point along the transfer and is executed immediately The 'Recall' can be applied once funds have been deposited. It can only be execrated on agreement with the receivers bank. I would suggest an additional 2 days for the receiver to transfer funds out is sufficient.

The 7 day proposed trade period is made up of: 3 working days for transfer +2 for trades at weekends + 2 for funds to be received and transferred onwards

[pazza83]

@chimp1984 regards fee splits

see @dav1dpgit's comments

Even if some banks allow for receivers to pay fees, the general SWIFT use case is the sending bank charges $20-30USD, and the receiving bank also takes a $10USD cut, sometimes. Just let each bank’s fees are borne by the bank account holder as the default (Senders and receivers anticipate their own banks’ fees.) If the sender wants to transfer all of the SWIFT fees to the other side via the wire process, explicitly say this is not standard and open to rejection of the SWIFT wire.

I agree with @dav1dpgit. Using the default fee split method is most simple. Both users will be aware of most fees. The sending party should know their own wire transfer fees, and the receiving party should know their own wire transfer fees. Some banks add in a fee + any bank intermediary fees (these can be unknown), however I do not think this is a reason not to add this payment method. Unknowns can be reflected in the trade price.

Shared fees can be clearly defined in the trade protocol. If the buyer of BTC passes all fees to seller this can be settled in mediation.

[pazza83]

@Conza88 thanks for all the comments I agree with all your points. Especially about SWIFT opening up more markets and increasing traders accessibility to exchange fiat with BTC from anywhere.

[pazza83]

I have made some proposals for putting a system in place to speed up decisions around new payment methods being added. Would welcome any comments bisq-network/growth#206

[chimp1984]

Just to make clear I am totally in favor to add SWIFT!

[pazza83]

Just to make clear I am totally in favor to add SWIFT!

Great 👍

Have you taken a look at the proposed fields https://github.com/bisq-network/bisq/issues/1789#issuecomment-591253226

Would it take much work to add?

[chimp1984]

Looks ok. So far I don't see much of extra work to normal bank account methods. Just a bit more fields. Maybe some fields like intermediary bank can be multiline all in one field so that the form does not get too long and that ui elements (like country selectors) dont get too much. I fear I am too busy with other stuff atm, but its an easy task for any dev. If no dev show up before next release ping me...

[pazza83]

Hi @bisq-network/mediators and @bisq-network/arbitrators I would like to implement SWIFT International Wire as a new payment method. Please let me know if you have any objections / feedback.

Would anyone from @bisq-network/bisq-devs be available to to take this on. I will package up the information required for you.

[pazza83]

I am keen to come to a decision on this by the end of this cycle.

I am proposing the add SWIFT as a payment option to Bisq. This seems to be roughly in line with the consensus.

It would be great to have @bisq-network/mediators input @huey735, @huey735, @Bisq-knight, @wiz and @leo816 please let me know if you have any concerns regarding mediating SWIFT trades.

[pazza83]

As per proposal for existing payment method editing process and estimated timelines

I am recommending this payment method for addition.

No concerns have been raised from @bisq-network/mediators so would like to make plans for getting this added in the next cycle.

@huey735, @huey735, @Bisq-knight, @wiz and @leo816 if you do have any concerns share them on this issue before the end of the cycle 27th Dec 2020.

[Conza88]

Nice. Regarding documentation - would suggest in the SWIFT model, maybe indication of higher fee's given through traditional banks... as opposed to Transferwise? lol. But should still very much be an option, given some can get banned from TW.

[Conza88]

But should still very much be an option, given some can get banned from TW.

As we've seen... with many getting deactivated/banned/accounts warned... SWIFT again raises it's head as best option imo.

Looked at many other's @pazza83 suggested all had negatives in terms of % fee's, conversion fee's etc. SWIFT basically being slower, but flat fee. Conversion probs not great, but I think scaling wise - ok option.

[pazza83]

Hi @bisq-network/bisq-devs is anyone available to take on adding SWIFT International Wire as a payment method?

[m52go]

What can we do to get this done? Is there a spec ready for a developer to pick it up?

[pazza83]

I think @sqrrm mentioned at the begging of the year they would be able to take this on, but I might be misremembering?

@sqrrm is this something you are available for if not is their another @bisq-network/bisq-devs that could take this on?

Everything is in place for the layout https://github.com/bisq-network/bisq/files/4253633/BISQ_SWIFT_Layout.pdf

@m52go is their a spec that has used before I could use as a template?

[wallclockbuilder]

@pedromvpg Can you convert the layout into actual UI or Wireframe? *Is there any other designer on the team I can reach out to ?