What does Bitpay do to avoid the fluctuation risk of exchange rate?

[realdos]

I understand that Bitpay is now serving as paypal in Bitcoin's world. They help merchants get their fiat money instantly while at the same time allow them to price the commodity on Bitcoin. But how does Bitpay itself avoid the risk of bitcoin rate fluctuation? Is there any hedge mechanism it uses to ensure its interest will not be jeopardized by the exchange rate change?

[1714179780]

1714179780

[1714179780]

1714179780

[1714179780]

1714179780

[1714179780]

1714179780

[1714179780]

1714179780

[CtrlAltBernanke420]

I do not know..... but i will take a stab at.

The only general concept I have been able to come up with, as I tried once to comprehend this and wound up frustrated...

Their recent multi-million dollar investment allows them to front end the risk. But generally speaking they take our already redundant and ineffecient banking system and make it more inefficient and more redundant. In essence they front you the cash, keep the bitcoin, have lots of bitcoins and cash on the exchanges(risk), allowing them to buy/sell bitcoins/cash before any of their cash transactions settle. IE sending funds to and from exchanges.

This model grows in risk as the ssize of transactions needing to be setteled in cash grow, as does the volatility increasing could reak havoc if trades are not managed properly or they are caught offgaurd by a very large transaction. As the price of bitcoin grows the risks begins to drop, again this is relative, so risk could actually grow.

[Terk]

I don't know what they actually do, so I'll write about what they might do.

1. When user clicks “I want to buy”, they lock a BTC-denominated price for him for the next 15 minutes. Since now, risk of exchange rate changes is on their side.
2. User can complete the transaction at any time between now and 15 minutes from now. They really can't know when. Or he may not complete and just drop out.
3. If they exchange BTC to fiat after user completes the payment, they risk more than their commission fee because BTC price is so volatile.

So I'd do it this way:

1. When user clicks “I want to buy”, they lock a BTC-denominated price for him for the next 15 minutes. Since now, risk of exchange rate changes is on their side.
2. They exchange BTC for fiat immediately after that, without waiting for the customer to actually pay. In bulk, eg. six times per minute, so every 10 seconds they exchange BTC to fiat for all transactions that were started within these 10 seconds.

But of course they don't exchange total volume of these started transactions as lot of these orders will drop out and will never be paid. They process fairly significant amount of transactions, so they can predict to some degree what percent of transactions will drop out and what percent will actually be finalized with a payment. They can segment that basing on website, transaction amount, time of day, and lot of other factors, to get pretty accurate.

So if they have 100 started transactions for total 200 BTC in the last 10 seconds, they should be able predict pretty accurately what BTC volume will actually go through. So they immediately exchange that amount of BTC which they think will be finalized for these started transactions.

3. After 15 minutes, when all these orders will be either paid or expired, they do additional exchange of some very fractional amount to correct what they missed. E.g. they exchanged 49 BTC for fiat based on their expected final volume from this 200 BTC started volume, but after 15 minutes it turned out, that 50 BTC were actually finalized. So they sell additional 1 BTC. Now their actual currency rate risk was much less than if they exchanged everything only after the fact. They actually risked changed rate for 1 BTC of 50 BTC transacted, so for 2% of traded volume. If price changed 2% in the wrong direction during these 15 minutes, they lost 2% of 2% = 0.04% of total. If they didn't convert BTC to fiat at the moment of starting orders and waited for finalizing these transactions, they would lost 2% of all 50 BTC so 2% of total volume, which is more than their fees.

This is just a statistics game. The more accurately they're able to predict transaction volume that will go through, basing on past performance and advanced segmentation, the lower their exchange rate risk is.

That is, assuming they do something like this. I would design it this way if I worked for them.

[realdos]

The solution I guess is a future contract to sell the bitcoin at a pre-agreed price. If a company could offer Bitpay this kind of contract, like people usually do in international trade industry, the risk could be hedged with acceptable transaction fee.

[gendal]

Surely the easiest approach is simply to charge a spread that covers the expected volatility in exchange rate during the period between offering a price and settling?

[realdos]

Surely the easiest approach is simply to charge a spread that covers the expected volatility in exchange rate during the period between offering a price and settling?

Yes it's the easiest way but not the best one..

The reason merchants use bitpay is that bitpay could help them solve the problem of fluctuated exchange rate. If bitpay instead charges the payer the spread that covers the expected volatility, it actually transfers the problem to the merchants' customers. A customer thus has to pay the cost which is supposed to be taken by bitpay, since it's bitpay's responsibility and what it is created for.

[subcoin]

2. They exchange BTC for fiat immediately after that, without waiting for the customer to actually pay.

"exchange" and "immediately" are the problems in this step.
None of the exchanges are "completely liquid".
Bitpay is not exactly "exchanging"; more like they are placing a sales order at the price that they gave to the customer.
That order may never be fulfilled. Or it may "hang" there for a while (hence, not exactly "immediate").

There is another way 

[Terk]

2. They exchange BTC for fiat immediately after that, without waiting for the customer to actually pay.

"exchange" and "immediately" are the problems in this step.
None of the exchanges are "completely liquid".

You can treat exchanges as “completely liquid” as long as you don't care about the price and as long as you don't have too big volume. Bitpay doesn't care about the price they sell BTC for as they exchange their customers' money - it just has to be some kind of “market prices”. So when they have this 0.5 BTC transaction to process, they can consider exchanges to be “completely liquid”.

Bitpay is not exactly "exchanging"; more like they are placing a sales order at the price that they gave to the customer.
That order may never be fulfilled. Or it may "hang" there for a while (hence, not exactly "immediate").

There is another way 

It's the other way around. Not placing a sales order at the price that they gave to the customer. They give the customer price calculated basing on current bid prices available at the exchanges and they simply put ask orders to match available bid offers - placing that ask order at the exchange at the same time as displaying the price to the customer (for some percentage of the transaction amount, basing on probability of the deal to go through). The whole process should work more in real time than I described in my previous post, but I wanted to simplify the example to be easier understandable, hence the 10-second periods.

[abbyd]

It's the other way around. Not placing a sales order at the price that they gave to the customer. They give the customer price calculated basing on current bid prices available at the exchanges and they simply put ask orders to match available bid offers - placing that ask order at the exchange at the same time as displaying the price to the customer (for some percentage of the transaction amount, basing on probability of the deal to go through). The whole process should work more in real time than I described in my previous post, but I wanted to simplify the example to be easier understandable, hence the 10-second periods.

Well, if they're market players, they'll only put in a BTC buy order when the BTC price is dropping. If BTC value is rising, they can pocket the BTC, and happily pay less cash than the coins will be worth in the future... As long as they have some bankroll (which they appear to), they should be fine.

[Terk]

Well, if they're market players, they'll only put in a BTC buy order when the BTC price is dropping. If BTC value is rising, they can pocket the BTC, and happily pay less cash than the coins will be worth in the future... As long as they have some bankroll (which they appear to), they should be fine.

This is just another business model and they really don't need to be a payment processor to play with that, they just need to have some bankroll to trade/speculate. And what if the price won't go up? What if the price plummets and will stay down for days or weeks or forever? I'm not sure if they want to add trading speculation complexity to everything they need to deal with. These are entirely different business models and I'm not sure if they're even compatible - trading speculation risks/mistakes could easily kill the entire business. My understanding is that their best bet is to try to make exchanging BTC to fiat as secure for them as possible, i.e. to try to exchange always at the price they locked for the customer - do this job well and the volume will take care of their earnings.

[ruggedman_dan]

Do BitPay merchants have the option of holding a portion of their revenue in Bitcoin?

For example, if my website selling golf balls makes 300 BTC a week, can I opt for BitPay to convert half into fiat and I keep the other half in coins?

[allthingsluxury]

Do BitPay merchants have the option of holding a portion of their revenue in Bitcoin?

For example, if my website selling golf balls makes 300 BTC a week, can I opt for BitPay to convert half into fiat and I keep the other half in coins?

Yes, this is an option that they have.

[molecular]

The solution I guess is a future contract to sell the bitcoin at a pre-agreed price. If a company could offer Bitpay this kind of contract, like people usually do in international trade industry, the risk could be hedged with acceptable transaction fee.

I don't know of any btc futures options market that handles such low timescales.

What Terk said in his first post makes sense to me. That's (roughly) how I pictured going about it.

[SamS]

I don't know what they actually do, so I'll write about what they might do.

1. When user clicks “I want to buy”, they lock a BTC-denominated price for him for the next 15 minutes. Since now, risk of exchange rate changes is on their side.
2. User can complete the transaction at any time between now and 15 minutes from now. They really can't know when. Or he may not complete and just drop out.
3. If they exchange BTC to fiat after user completes the payment, they risk more than their commission fee because BTC price is so volatile.

So I'd do it this way:

1. When user clicks “I want to buy”, they lock a BTC-denominated price for him for the next 15 minutes. Since now, risk of exchange rate changes is on their side.
2. They exchange BTC for fiat immediately after that, without waiting for the customer to actually pay. In bulk, eg. six times per minute, so every 10 seconds they exchange BTC to fiat for all transactions that were started within these 10 seconds.

But of course they don't exchange total volume of these started transactions as lot of these orders will drop out and will never be paid. They process fairly significant amount of transactions, so they can predict to some degree what percent of transactions will drop out and what percent will actually be finalized with a payment. They can segment that basing on website, transaction amount, time of day, and lot of other factors, to get pretty accurate.

So if they have 100 started transactions for total 200 BTC in the last 10 seconds, they should be able predict pretty accurately what BTC volume will actually go through. So they immediately exchange that amount of BTC which they think will be finalized for these started transactions.

3. After 15 minutes, when all these orders will be either paid or expired, they do additional exchange of some very fractional amount to correct what they missed. E.g. they exchanged 49 BTC for fiat based on their expected final volume from this 200 BTC started volume, but after 15 minutes it turned out, that 50 BTC were actually finalized. So they sell additional 1 BTC. Now their actual currency rate risk was much less than if they exchanged everything only after the fact. They actually risked changed rate for 1 BTC of 50 BTC transacted, so for 2% of traded volume. If price changed 2% in the wrong direction during these 15 minutes, they lost 2% of 2% = 0.04% of total. If they didn't convert BTC to fiat at the moment of starting orders and waited for finalizing these transactions, they would lost 2% of all 50 BTC so 2% of total volume, which is more than their fees.

This is just a statistics game. The more accurately they're able to predict transaction volume that will go through, basing on past performance and advanced segmentation, the lower their exchange rate risk is.

That is, assuming they do something like this. I would design it this way if I worked for them.

Interesting. Thanks for the explanation. The key is the reliability of your forecasting system. I'd assume they'd have to stop making a market in volatile times as their likely to get swamped -- unless they have a metric for that as well.