Exchange Rate Options (excluded 2.03)

This proposal is part of the 2.03 upgrade process. Please comment by replying below

The standard currently does not accommodate the reporting of specific exchange rates that might be tied to a transaction. Rather, a value-date allows for users to convert the reported value into any currency using standard historical lookup tables (maintained inter alia by the IMF and OECD). There are, however, legal and operational use cases where the explicit reporting of a specific exchange rate may be necessary.

The Open Contracting Data Standard (OCDS) has also been exploring this issue and is considering two options which translate in IATI terms to:

Option One

  • transaction/value/@alt-currency - the secondary currency
  • transaction/value/@alt-value - the value in alt-currency
  • transaction/value/@exchange-rate - conversion between value and alt-value on @value-date

Option Two

  • transaction/value/exchange-rate/@currency - the secondary currency
  • transaction/value/exchange-rate/@rate - the exchange rate from transaction/value/@currency to secondary currency on transaction/value/@value-date

We could EITHER adopt one of these options OR we could postpone this proposal and engage in the OCDS discussion to adopt a common approach between the standards.

In option Two, which exchange-rate will be used? I believe there are different types of exchange-rates in existence (market, non market). If IATI does not provide guidance on that, the conversions will become rather meaningless. (will post to OCDS #384) as well for further consideration.

Thanks for bringing this up @bill_anderson

Re @siemvaessen’s point on which rate would be used - we had a bit of discussion last year about exchange rates. There are some useful screenshots at the bottom of that post from @matmaxgeds which I think explains the sort of data we need for a particular use case (debt management at country level). In this case, there is an exchange rate specified in the agreement between the creditor and debtor. This would probably need to be specified at transaction level as it could fluctuate over time based on some agreed formula as specified in the agreement.

I think option 2 might be preferable because it could allow multiple currencies (if multiple exchange-rates were allowed per value)

Based on these discussions, I’ve updated the proposal for OCDS at in which:

  • The approach we’re proposing would be more in-line with Option 2, particularly when transaction/value/exchange-rate can exist multiple times;
  • I’ve added a source attribute to the idea of an exchange rate, that could be used to indicate whether the rate was agreed in a contract, came from market rates, or came from the application that is producing/consuming the data

I’m not certain that in either option for IATI the assumption can be made that the conversion is the rate from transaction/value/@value-date: would need to think more on this.

It is proposed that this topic is postponed until the next upgrade to allow for further consultation and alignment with the open contracting community.

If you feel that this should still be included in the current upgrade, please do respond here