Exchange Support

Each exchange supports a wide variety of currencies and markets. There is little conformity between exchanges and most choose their own adventure. The crypto tax reporting software needs to know what markets are supported by the exchange so that it do price lookups when determining the value of an asset (more on that later). If the exchange doesn't support USD (e.g. Binance) we need to know that so we don't try and do price lookups for ETHUSD. In the case of Binance they support USDT so we can successfully do price lookups for ETHUSDT.

Not all exchanges publish their price data. We sometimes need to look at other exchanges for prices. In this case currency symbols need to be standardised. Exchanges sometimes like to store currency names differently and come up with their own naming format. For example Kraken stores Bitcoin as XXBT and USD as ZUSD whilst most other store is as BTC and USD respectively. If we need to do a price lookup for a Kraken currency on a different exchange we need to know what it's called on the price lookup exchange. It's the job of the crypto tax reporting software to do this standardisation and find accurate prices for any symbol.

Each exchange supports a wide variety of currencies and markets. There is little conformity between exchanges and most choose their own adventure. The crypto tax reporting software needs to know what markets are supported by the exchange so that it do price lookups when determining the value of an asset (more on that later). If the exchange doesn't support USD (e.g. Binance) we need to know that so we don't try and do price lookups for ETHUSD. In the case of Binance they support USDT so we can successfully do price lookups for ETHUSDT.

Not all exchanges publish their price data. We sometimes need to look at other exchanges for prices. In this case currency symbols need to be standardised. Exchanges sometimes like to store currency names differently and come up with their own naming format. For example Kraken stores Bitcoin as XXBT and USD as ZUSD whilst most other store is as BTC and USD respectively. If we need to do a price lookup for a Kraken currency on a different exchange we need to know what it's called on the price lookup exchange. It's the job of the crypto tax reporting software to do this standardisation and find accurate prices for any symbol.

When you get a file import you will almost always see the symbol you've sold or bought represented as ASSET + CURRENCY, e.g. ETHUSD. Exchanges have their own method of coming up with the format for storing theses. Here are some examples:

• ETHUSD (Kraken, Binance, Coinbene, Coineal, HitBTC, Huobi Global)
• ETH/USD (Bitfinex, Bitstamp, KyCoin, Cryptopia, BitMax, BX Thailand)
• ETH-USD (Coinbase, Bittrex, LBank, BTC Markets, Okex, Okcoin)
• ETH_USD (Trade Satoshi, P2pb2b, ZB, Bibox)

The story doesn't end here. Some exchanges reverse the asset and currency positions so they list their symbols as CURRENCY + ASSET. An example of this is DigiFinex.

The important thing here is that we need to know which is the asset (the currency purchased) and which is the currency (the item used to do the purchasing). The tax calculator software needs to split these two parts so that it can determine the cost basis (what you originally paid for something after you sold it).

The cost basis is the all important factor for determining the amount of tax payable and there's usually a conversion process involved.

Say you bought Ethereum (ETH) with Bitcoin (BTC). In order to calculate how much ETH was worth when you bought it we often need to know it's value in a fiat currency. In order to do this we need to split it away from BTC and 'attach' a fiat currency like USD. The symbol then becomes ETHUSD. We can now value the coin you purchased in a fiat currency.

The challenge is that a parser (or splitter) like '/' is not always used between the asset and the currency. For example Binance doesn't use a parser on their exports. You first thought might be to split them buy character length; 3 for the asset and 3 for the currency. That won't work because symbols don't always follow a 6 character pattern (STORJBTC, ABYSSETH, AMBBNB, AMZNTUSDT, ATOMUSDC, BCHABCPAX).

The only real way to accomplish this is for the crypto tax reporting software to 'know' what assets and currencies are supported by the exchange. And the best way to do this is to query the exchange directly by connecting to them on a daily basis and saving their data. This is accomplished through web API calls. We can get detailed records directly from the exchange about what assets and currencies they support along with other data. Here's an example from Binance which you can find at Binance exchange info API address

...{
   "symbol": "RLCBTC",
   "status": "TRADING",
   "baseAsset": "RLC",
   "baseAssetPrecision": 8,
   "quoteAsset": "BTC",
   "quotePrecision": 8,
   "orderTypes": [
      "LIMIT",
      "LIMIT_MAKER",
      "MARKET",
      "STOP_LOSS_LIMIT",
      "TAKE_PROFIT_LIMIT"
   ],...

Not all exchanges support downloading of all their data. Some support trades but not deposits or withdrawals. Some support CSV files other support Excel files. The Exchange's API also offers different options. Many support trades but not deposits or withdrawals. All of this info must be known to the crypto tax reporting software.

Which column is the date column? What format is it stored as (the COSS exchange stores it's date in Israel date format)? Does it store time in Universal Time Clock (UTC) or in the local time of the users trading account (Bitfinex for example). If it does store the date in the local time, what region is it from?

Some exchanges have changed the way they store data on their import files and API. You have some users with the old format and other users with the new format. Yes, the crypto tax reporting software needs to support both versions in order to create a smooth experience for the user.

There are so many variances in the way exchanges store their export data. No two exchanges are alike. To bring data across all exchanges into a single standardised format requires ingenuity in the software.

Did you know that many deposit and withdrawal exports have a column indicating whether the deposit or withdrawal was successful? The import needs to filter out records that did not complete properly otherwise you get redundant records.

Some exchanges store their buy and sell transactions using a positive and negative symbol against the quantity value. Others have a 'buy' or 'sell' flag on the record. Not all exchanges have a quantity value. You need to work that out from the unit price and the total outlay.

What a disaster if the user accidentally imported the same file twice (or more). This is fairly easy to do. What about the API import, what happens when the user gets data from the same period? It's too easy for mistakes to happen so the crypto profit calculator software needs to manage duplicates and either skip them (in the case of API imports) or alert the user in the case of file imports. API imports are often easier as the unique ID of the record can be recorded and skipped if the user tries to import a record with the same ID.

File imports are harder because not all exchanges export the unique ID of the record in the export data. In these cases we need to check across several columns and determine the overall number of potential duplicates to determine if the file has already been imported.