The complexity of full multiple currency support

Unknown

This is my general observations on multiple currency support, and some information directly related to the implementation of it in Quicken Windows.

1. When dealing with multiple currencies you can never accurately state total value using only one currency.
2. It might be convenient to use the current exchange rate in a transaction, but if it is correct is purely chance.

Currencies are traded 24/7, and in different places, with different fees.
I can state that I have 13.34 shares of IBM.  I can never state its exact value until I sell and change it into some currency.  But even then my value in say USD for my 13.34 shares of IBM tells me nothing about the value of someone Else's 13.34 shares of IBM in USD.

The same is true with currency.  I can state I have $103.33 USD, but I can't accurately state what its value is in any other currency.  I can convert to another currency and then it is accurate in that currency, but not in USD any more.

So if I pull up a net worth graph over time that includes multiple currency, it is always an estimate for any given value.  In some ways it is more of an estimate than the IBM example, in others it is more exact.  If I trade IBM on a given exchange, that exchange closes for the day.  So after the close I can get the number for the day and use that.  Currency exchange rates never "close" so basically there isn't really a "day" number.  But in fact the same can be said even in the IBM example since just because a security closed for the day at a given value that doesn't mean you can get that when the the exchange opens.  So in fact you know less about the value of the IBM shares during the night than you do with a currency.  But even that isn't "exact" because there are multiple currency exchanges, which are not going to be exactly the same.

In Quicken when you do a transfer from one account that has a given currency, to another account that has a different currency it will by default give you the "other account" amount based on the current exchange rate.  This may be convenient, but it being accurate would be pure chance.  First off there is no reason to believe that you will be getting that number from your financial institution. Not to mention fees and such which might be incorporated into the amount received without being broken out.  But even if it was accurate, it won't be by the time you press OK.  The proper way to record this transaction would only be to use the value that the financial institution has given.

Using the current exchange rate for any given transaction would be the equivalent of me saying that I can look at the current price of IBM and press button for Buy at market, and believe that I will get my IBM shares for that amount.

Of course even to have an approximation on a net worth graph requires the exchange rate on that "day" (whatever that really means), which the US Windows version doesn't do.
And course you have actually apply those exchange rate numbers to values on the report/graph, which the Canadian version doesn't do.

There are other complexities for "full currency support", like if you were going to allow multiple currencies in an account.  If you were to do that you would pretty much have the same kind of complexity that you have in a brokerage account.  There would never be a "cash" number.
For instance in my Vanguard accounts there is never any "cash".  The money is always in one security or another.  Now some securities track the US dollar exactly so that you have a "cash equivalent", but if I sell IBM the proceeds don't go to cash they go into a buy of another security.

Doing this would require a lot more overhead than the single number that is now required.
That overhead would be in storage space, time to process, and complexity of coding it.

smayer97

I think you might be overthinking this a bit. It sounds like you are thinking in the context of trading currency markets as they fluctuate 24/7.

But for financial planning and record keeping, there are actually conventions to deal with this. And for many people, these are mandated by the government, which would serve the average person. For example, in Canada for tax purposes, there are 3 possible scenarios. One scenario is that you would be required to use the Bank of Canada official exchange rate; this used to be the noon rate (ET) but as of this year it is being changed to the close rate (officially 5 pm ET, standard defined end of day for currencies). The other is the ability to override that rate and use an actual rate used in the transaction, such as when determined by another source like your credit card company. Third is the use of a yearly average, again determined by the Bank of Canada.

So to implement this would simply require for Quicken to first download official rates. Second to allow overriding the official exchange rate based on a rate stored at the transaction level (or simply the actual amount recorded in the transaction), and third, the option to use the average rate, which I think the simplest would be to require the user to enter the rate once for each year. All of this I believe is quite straight-forward to implement, and accommodates most common usage. And I would suggest a simple user option to determine whether to use the yearly average or the official daily rates, but transaction level rate would always take precedence. Then the program would only need to look in 3 places, the average rate or the daily rate, only overridden if there is a transaction level rate. This set-up would still accommodate the user that wants to use all transnational level currency conversion.

As for the impact, unless a user has lots of trading activity, I do not expect this to have a large performance impact. And if it does, maybe there simply needs to be an option presented to only perform conversion on demand when reports and graphs are being created, with a warning of the impact.

Unknown

smayer97 (QM2007, CDN user since '92) said:

I think you might be overthinking this a bit. It sounds like you are thinking in the context of trading currency markets as they fluctuate 24/7.

But for financial planning and record keeping, there are actually conventions to deal with this. And for many people, these are mandated by the government, which would serve the average person. For example, in Canada for tax purposes, there are 3 possible scenarios. One scenario is that you would be required to use the Bank of Canada official exchange rate; this used to be the noon rate (ET) but as of this year it is being changed to the close rate (officially 5 pm ET, standard defined end of day for currencies). The other is the ability to override that rate and use an actual rate used in the transaction, such as when determined by another source like your credit card company. Third is the use of a yearly average, again determined by the Bank of Canada.

So to implement this would simply require for Quicken to first download official rates. Second to allow overriding the official exchange rate based on a rate stored at the transaction level (or simply the actual amount recorded in the transaction), and third, the option to use the average rate, which I think the simplest would be to require the user to enter the rate once for each year. All of this I believe is quite straight-forward to implement, and accommodates most common usage. And I would suggest a simple user option to determine whether to use the yearly average or the official daily rates, but transaction level rate would always take precedence. Then the program would only need to look in 3 places, the average rate or the daily rate, only overridden if there is a transaction level rate. This set-up would still accommodate the user that wants to use all transnational level currency conversion.

As for the impact, unless a user has lots of trading activity, I do not expect this to have a large performance impact. And if it does, maybe there simply needs to be an option presented to only perform conversion on demand when reports and graphs are being created, with a warning of the impact.

First I was talking about accuracy, not in conventions that one country or another might have.  In fact talking about that complicates things even more since it will not be the same for different countries.

Frankly I doubt most people would want to use a yearly average for any of this unless the graph was divided by years.

But sure just like we use the closing price for a security you can use the closing of a given exchange/country time for currencies for the graph/report.  The point was only to point out that it is an estimate, not exact.  Which is fine as long as people understand that.  And I wasn't "choosing" the right way for Quicken to implement this.  Just pointing out an underline truth/assumption.

#2 was actually a more important point though.  And that is currently Quicken Windows gives the user the option to use the current exchange rate to calculate the amount for the other side of the transaction.  Still nothing "really" wrong with that provided that they user understands that it an estimate and they can't count on amount.

It was recently brought to my attention that this isn't understood by some people.
As comparing the numbers between two different versions of Quicken (or even the same version of Quicken) using data files that started out the same, but are maintained separately.
The moment you use this convenience function you can no longer compare values exactly between the two.

Unknown

smayer97 (QM2007, CDN user since '92) said:

I think you might be overthinking this a bit. It sounds like you are thinking in the context of trading currency markets as they fluctuate 24/7.

But for financial planning and record keeping, there are actually conventions to deal with this. And for many people, these are mandated by the government, which would serve the average person. For example, in Canada for tax purposes, there are 3 possible scenarios. One scenario is that you would be required to use the Bank of Canada official exchange rate; this used to be the noon rate (ET) but as of this year it is being changed to the close rate (officially 5 pm ET, standard defined end of day for currencies). The other is the ability to override that rate and use an actual rate used in the transaction, such as when determined by another source like your credit card company. Third is the use of a yearly average, again determined by the Bank of Canada.

So to implement this would simply require for Quicken to first download official rates. Second to allow overriding the official exchange rate based on a rate stored at the transaction level (or simply the actual amount recorded in the transaction), and third, the option to use the average rate, which I think the simplest would be to require the user to enter the rate once for each year. All of this I believe is quite straight-forward to implement, and accommodates most common usage. And I would suggest a simple user option to determine whether to use the yearly average or the official daily rates, but transaction level rate would always take precedence. Then the program would only need to look in 3 places, the average rate or the daily rate, only overridden if there is a transaction level rate. This set-up would still accommodate the user that wants to use all transnational level currency conversion.

As for the impact, unless a user has lots of trading activity, I do not expect this to have a large performance impact. And if it does, maybe there simply needs to be an option presented to only perform conversion on demand when reports and graphs are being created, with a warning of the impact.

P.S. On storage, performance, and complexity of the code.  It all depends on what is implemented, and what is OK.  As I have stated perfect accuracy isn't possible.  But the point is the the more you push towards that goal the more it costs you.

That is in fact why there are compromises/conventions like you mentioned.

smayer97

smayer97 (QM2007, CDN user since '92) said:

I think you might be overthinking this a bit. It sounds like you are thinking in the context of trading currency markets as they fluctuate 24/7.

But for financial planning and record keeping, there are actually conventions to deal with this. And for many people, these are mandated by the government, which would serve the average person. For example, in Canada for tax purposes, there are 3 possible scenarios. One scenario is that you would be required to use the Bank of Canada official exchange rate; this used to be the noon rate (ET) but as of this year it is being changed to the close rate (officially 5 pm ET, standard defined end of day for currencies). The other is the ability to override that rate and use an actual rate used in the transaction, such as when determined by another source like your credit card company. Third is the use of a yearly average, again determined by the Bank of Canada.

So to implement this would simply require for Quicken to first download official rates. Second to allow overriding the official exchange rate based on a rate stored at the transaction level (or simply the actual amount recorded in the transaction), and third, the option to use the average rate, which I think the simplest would be to require the user to enter the rate once for each year. All of this I believe is quite straight-forward to implement, and accommodates most common usage. And I would suggest a simple user option to determine whether to use the yearly average or the official daily rates, but transaction level rate would always take precedence. Then the program would only need to look in 3 places, the average rate or the daily rate, only overridden if there is a transaction level rate. This set-up would still accommodate the user that wants to use all transnational level currency conversion.

As for the impact, unless a user has lots of trading activity, I do not expect this to have a large performance impact. And if it does, maybe there simply needs to be an option presented to only perform conversion on demand when reports and graphs are being created, with a warning of the impact.

BTW, as for use of average, this average exchange rate for any given year would be applied
to each transaction, regardless of the period displayed in report/graph.

But sure, if you are just raising awareness re: pure accuracy, I understand what you are getting at. That is good for people to be aware of this.

My general point is that when recording keeping, the purpose has to be defined, which will define the most appropriate application of exchange rates, hence, my example as it applies in Canada.

smayer97

smayer97 (QM2007, CDN user since '92) said:

I think you might be overthinking this a bit. It sounds like you are thinking in the context of trading currency markets as they fluctuate 24/7.

But for financial planning and record keeping, there are actually conventions to deal with this. And for many people, these are mandated by the government, which would serve the average person. For example, in Canada for tax purposes, there are 3 possible scenarios. One scenario is that you would be required to use the Bank of Canada official exchange rate; this used to be the noon rate (ET) but as of this year it is being changed to the close rate (officially 5 pm ET, standard defined end of day for currencies). The other is the ability to override that rate and use an actual rate used in the transaction, such as when determined by another source like your credit card company. Third is the use of a yearly average, again determined by the Bank of Canada.

So to implement this would simply require for Quicken to first download official rates. Second to allow overriding the official exchange rate based on a rate stored at the transaction level (or simply the actual amount recorded in the transaction), and third, the option to use the average rate, which I think the simplest would be to require the user to enter the rate once for each year. All of this I believe is quite straight-forward to implement, and accommodates most common usage. And I would suggest a simple user option to determine whether to use the yearly average or the official daily rates, but transaction level rate would always take precedence. Then the program would only need to look in 3 places, the average rate or the daily rate, only overridden if there is a transaction level rate. This set-up would still accommodate the user that wants to use all transnational level currency conversion.

As for the impact, unless a user has lots of trading activity, I do not expect this to have a large performance impact. And if it does, maybe there simply needs to be an option presented to only perform conversion on demand when reports and graphs are being created, with a warning of the impact.

As for compromises/conventions it is not just a matter of performance but also a function of available data, and even as you point out, there can be more than one answer to the same question, depending from which side you are referring to about a specific transaction...like when your bank includes a typical 2.5% surcharge built into the exchange rate, etc.

So, though intellectually interesting, since ultimately this is about Quicken and financial record keeping, we have to bring it to a practical level, kinda like time zones... ;-)

Unknown

smayer97 (QM2007, CDN user since '92) said:

I think you might be overthinking this a bit. It sounds like you are thinking in the context of trading currency markets as they fluctuate 24/7.

But for financial planning and record keeping, there are actually conventions to deal with this. And for many people, these are mandated by the government, which would serve the average person. For example, in Canada for tax purposes, there are 3 possible scenarios. One scenario is that you would be required to use the Bank of Canada official exchange rate; this used to be the noon rate (ET) but as of this year it is being changed to the close rate (officially 5 pm ET, standard defined end of day for currencies). The other is the ability to override that rate and use an actual rate used in the transaction, such as when determined by another source like your credit card company. Third is the use of a yearly average, again determined by the Bank of Canada.

So to implement this would simply require for Quicken to first download official rates. Second to allow overriding the official exchange rate based on a rate stored at the transaction level (or simply the actual amount recorded in the transaction), and third, the option to use the average rate, which I think the simplest would be to require the user to enter the rate once for each year. All of this I believe is quite straight-forward to implement, and accommodates most common usage. And I would suggest a simple user option to determine whether to use the yearly average or the official daily rates, but transaction level rate would always take precedence. Then the program would only need to look in 3 places, the average rate or the daily rate, only overridden if there is a transaction level rate. This set-up would still accommodate the user that wants to use all transnational level currency conversion.

As for the impact, unless a user has lots of trading activity, I do not expect this to have a large performance impact. And if it does, maybe there simply needs to be an option presented to only perform conversion on demand when reports and graphs are being created, with a warning of the impact.

Well yes your example applies to Canada, and not the US.  Which breaks the model that one method can be applied to all countries.  Which in turn increases the complexity of supporting it in Quicken.  Not to mention people disagreeing on how it should work.