About Our Products
Last updated
Last updated
Multi-dealer marketplace for businesses in crypto.
You need to get access to the production environment trade.finerymarkets.com and have the trading limits set.
You can do it either in GUI or via API. In GUI, open Trading tab where you can see a tradable order book, an order input form and last trades. Choose an asset and then specify price for limit orders, size, side and order type. Feel free to use the Client Order Id field if you need it.
Order book displays accessible liquidity that is unique for a particular taker. If a taker does not have sufficient free Global and/or Counterparty limits, a part of the orders placed by liquidity providers is not displayed and is not tradable.
These are 2 order types. Market order is an order that must be immediately filled at any market price while Limit order is an order that must be immediately filled at the specified limit price or better. Market and Limit orders may be either IOC or FOK.
Immediate-or-Cancel (IOC). If it is not completely filled, the remaining amount will be cancelled. Partial fills are allowed.
Fill-or-Kill (FOK). FOK order is an order that must be immediately filled entirely. Otherwise, it will be totally cancelled. No partial fills are allowed.
Please keep in mind that we don’t offer resting limit orders. Thus, you will be able to place orders if there is a price to match it. For example:
1 BTC = $10 on Finery Markets
You place the order where 1 BTC = $9
Your order will be rejected until there’s a price to match
However, if you place the 1 BTC = $10 it will be immediately executed
Finery Markets has a maker-taker concept. There are two types of users on the Platform: a maker and a taker.
A market maker provides liquidity by posting orders to the Firm Order Book; it may use "limit" and "postOnly" order types. Self-trades are prohibited.
A market taker consumes liquidity and may use "marketIOC", "marketFOK", "limitIOC" and "limitFOK" order types.
A maker's order may be matched only to an order of a taker; maker-maker trading is prohibited. Thus, it may lead to a situation when the price of an ask order is lower than the price of a bid order.
- Tier 3: 3 bps applied if the turnover is less than $50 mln - Tier 2: 2 bps applied to the turnover is ≥$50 mln and < $200 mln - Tier 1: 1 bps applied to the turnover is >$200 mln
As a result of trading, the Platform calculates net positions to settle in real-time. Post-trade counterparty settlement is peer-to-peer and may be in the form of a blockchain transaction, bank wire, or alike. The Platform is never a side to any deal and is not involved in the actual settlement. However, the Platform requires information about settled trades in order to apply updated limits to trading. A settlement (see the Settlements tab) is created when a settlement order is executed (i.e., settled). A settlement order is executed when a settlement transaction (see the Transactions tab) is committed (i.e., confirmed) by a receiving trading party.
Yes, you will receive a daily statement showing your limits, open positions, trades and settlement.
The sum of deals and settlements (i.e., settled deals) is an open position. For example, if you have bought 1 BTC for 10000 USD, your open positions are +1 BTC and -10000 USD; if then you have settled 0.6 BTC against 6000 USD and sold 0.4 BTC for 4100 USD, your resulting positions are 1-0.6-0.4=0 BTC and -10000+6000+4100=100 USD. You can see your current open positions on the Trades tab.
The central part of the concept is counterparty limits (please read Limits Explained). You can make a trade only if you have trading limits set and your free limits are positive.
there are Global limits, which apply to the overall activity of a user, and Counterparty limits, which apply to a particular counterparty of a user
there are also Net limits and Gross limits
Net Limit Utilization is equal to the current P&L of all open positions
Gross Limit Utilization is equal to the max of an abs value of all short positions and abs value of all long positions (see examples below)
The values of each limit are defined and set by a user (via API or in GUI: Trade > Limits). When calculating utilization, the Platform takes into account open orders and unsettled transactions; worst-case scenario approach is applied. Available for trading Net/Gross limit equals Net/Gross limit minus utilization.
The Gross limit is regulating the maximum possible open position a taker or a maker may open (exposure). You can make a trade only if you have trading limits set and your free limits are positive. You have 2 limits:
Both makers and takers should set a global gross limit to start trading. It regulates the maximum possible open position across all counterparties
In order to start trading with each other, counterparties should set their counterparty limits against each other. It regulates the maximum possible open position with a particular counterparty
Both of the limits use the following formula to calculate the gross limit utilization (exposure): Your exposure=MAX( |SUM(Long positions)|, |SUM(Short positions)| ) Example of positions expressed in gross limit The Counterparty Gross limit is 800000 USD
BTC
+10
If 1 BTC equals 20000 USD
USD
+200000
ETH
-300
If 1 ETH equals 1200 USD
Calculation = MAX(|+200000+200000|,|−360000|) Your exposure equals 400000 USD, and your free gross limit is (800000 − 400000) = 400000 USD. This means that you are able to buy or sell additional 20 BTCs (or equivalent quantities of other assets) at this given moment.
Equity represents the result of your trading in the selected currency (i.e. your balance) EQUITY = SUM(Positions)
BTC
+10
If 1 BTC equals 20000 USD
USD
+200000
ETH
-300
If 1 ETH equals 1200 USD
Calculation = (+200000 USD +200000 USD - 360000 USD) = 40000 USD
No, Finery Markets is a non-custodial platform, however, you will need to settle your open position against a market-maker.
Finery Markets is a peer-to-peer platform with post-trade settlement. This means that trading parties settle open positions directly with each other. In order to facilitate the settlement process, the Platform provides for a protocol that allows:
Settlement Request, which is sending and receiving general requests for settlement;
Settlement Transaction, which is sending and receiving information about a particular settlement transaction.
Settlement Request can be sent to any counterparty with a mutual counterparty limit. It specifies only the asset that an initiator wants to receive. Settlement Transaction is designed to send information about an actual blockchain transaction or a bank wire. Thus, it requires not only eligible counterparty but also an asset and its quantity:
There is a restriction applied to adding a settlement transaction - the initiator must have a negative position in a specified asset against the counterparty, thus, the specified amount of the asset must be positive. The rationale here is that the initiator can add only such a settlement transaction that reduces the open position of a specified asset. Besides, an initiator cannot send more than it owes.
Once a settlement transaction is added, a respected settlement order is created in the Platform; to send a settlement transaction an initiator must add TxId (it might be a hash of a blockchain transaction or a bank reference); once a settlement transaction is committed by the recipient, a respected settlement order is executed and a settlement deal is created in the Platform.
For Takers If you intend to request a settlement below the threshold of your Liquidity Provider (Market Maker), put the tick in the “Fee paid by me” checkbox. The fee will be deducted from the requested amount, thus the amount you will receive to your wallet or custodian account will be smaller than the one you have requested. The fee amount will be shown in your settlement history.
If you use API for automated settlements, please note that the amount will not be adjusted in the incoming settlement transaction. You will have to deduct the Network Fee from the Amount on your end. Hence the amount in the transaction will differ from the amount received by your wallet.
For Makers
If the Taker sends the Settlement Request with Efx::Flags 1 - Fee paid by recipient , kindly note that you must specify the network fee when sending the settlement transaction.
For example:
The Taker requests 18 000 USDT with Flag 1
Send the 18 000 USDT deducting the fee. For instance 17800 USDT sent and 200 USDTs were the network fee.
Upon initializing the the settlement transaction input the 18 000 in amount and 200 in Network fee
You can find the relevant API documentation here.
Examples for API implementation on GitLab
Finery Markets offers an extensive list of API methods that cover 100% of the platform’s features. To attain bespoke performance the users must comply with the suggested practices listed below
If you are using the FIX protocol, please make sure you don’t have two instances of separate connections from one IP. FM core won’t respond back to the one that attempts to connect later, since we consider that there’s an active logon session already.
Please mind that the ‘heartbeat’ functionality is not enabled for FIX sessions at the moment. If you wish to check connectivity, please sent a TEST message instead.
We urge connecting only to the instruments intended for trading. You may use instruments whitelisting in the GUI to limit the available instruments.
X-check that you are not subscribed or requesting methods that are not in use
When using FIX, please use 2 separate API keys. The 1st one is for Market Data, and the 2nd one is for trading.
FM Market data is updated every 25 ms per instrument by default. We recommend that you test your system with that load in mind or design a throttling logic on your end. Note that market data throttling doesn’t impact order execution.
The golden standard for supplying liquidity:
Whenever you need to modify an order, use /mod instead of canceling the previous order and submitting a new one
Don’t update the order unless you intend to change price/quantity of the order; your current order won’t expire
NB: Finery Markets has a speedbump of 100ms for takers to protect you from the toxic flow
We offer markups per pair (individually bid & ask) and per client hence we suggest streaming a raw orders to Finery Markets. The markups can be adjusted via API or GUI
There’s a rate limit of 2000 RPS per account on FIX API (and it will be extended to WS)
In most cases you have more than one API key. Please always make sure you are using the one with appropriate access level: View only | Trading allowed | Settlements allowed, etc (see Multi-Roles for the full list). If you are receiving “Error 3: Not authorised” it’s likely that you are using a wrong API key.
Make sure your are not using same API key with multiple asynchronous REST clients, as in this case nonce system may malfunction (which is not a bug, but a valid security alert). In this case you should receive “Error 6: Invalid nonce”.
Q: How to find the last nonce without a key reset?
A: We recommend using a timestamp (e.g., 1674504823). This way, you will always understand the logic behind it, and your next timestamp will always be greater than the previous one.
Make sure your system clock is synchronized.
Make sure your payload contains a "timestamp" field.
Make sure you use UTC time.
Make sure it is in milliseconds.
Make sure the are no delays between setting a timestamp and sending a request.
FM API supports all features available in UI, including non-trading (risk management, user management, etc)
We recommend avoiding excessive requests on non-trading API features, as that may affect the system performance. Non-trading API features often are more resource consuming and are designed to be less latency sensitive from our end.
Here are some examples of non-optimal use of the API and clarifications of recommended behavior.
Don’t request trade history after every trade, especially without filters narrowing down the response
Instead: Listen to trade execution report over WS / FIX
Don’t update risk limits at every tick of market data to adjust to the conversion rate
Instead: Add instrument limits for the respective asset
Make sure you do not send invalid requests.
Make sure you don’t create too many connections and do not reconnect often.
If you need to request same data frequently, check if it is possible to use a data feed instead.
If you wish to monitor a particular order’s execution, don’t request the entire history. Instead:
wait for a response to the request, or
use Feed 'O' to subscribe to a particular order
One of the most frequent errors during integration is caused by a lack of understanding of the concept of the balance step. If you are receiving “83 Invalid order volume Please check that the data type in the order matches the data type in /add” - this may be the reason. Please:
Refer to Data Types
Use POST api/instruments to see the balance step (Efx::Size) for the existing instruments
Example: you need to correctly populate the USDT order size for an order of 4536.15 USDT.
From the Data Types reference you know that one unit is equal to 0.00000001 (1e-8) fraction of the asset unit.
You call POST api/instruments and see that USDT has a step of 100
0.00000001 * 100 = 0.000001 or 6 decimals
Hence, the correct order size to use would be: 4536.15 ÷ 0.000001 = 4536150000
The FM approach to rounding is that we round the purchase value up to the nearest decimal of the asset being acquired, in favor of the market maker. We do it in favor of the maker in order to prevent potential fraudulent behavior (repeatedly buying huge quantities of satoshis for $0.001 (which would essentially be “free” with standard rounding).
FM operates under a taker-maker model; takers only consume liquidity. Due to that, taker accounts cannot create resting limit orders - orders that are placed in the order book but are not immediately executable because the specified limit price has not yet been reached.
The limit orders available to the taker accounts are:
LimitIOC - an aggressive (liquidity consuming) order that attempts to execute at the specified price and is canceled immediately after the attempt, regardless whether it has been filled, partially filled or not filled at all. ‘IOC’ stands for ‘immediate or cancel’
LimitFOK - an aggressive (liquidity consuming) order that attempts to be immediately fully filled at the specified price and is canceled if that’s impossible. ‘FOK’ stands for ‘fill or kill’
Example:
Size
Price
3
60000
2
58200
4
58100
2
58000
Imagine the table above is our tradable Bitcoin order book. Under such market conditions:
A limitIOC buy order with size = 3, price = 58100 will get filled with 2 BTC @ 58000 and 1 BTC at 58100
A limitIOC buy order with size = 3, price = 57000 will be canceled unfilled (because there are no asks at this price at all)
A limitFOK buy order with size = 3, price = 58500 will get filled with 2 BTC @ 58000 and 1 BTC at 58100
A limitFOK buy order with size = 3, price = 58000 will get canceled unfilled (because there’s not enough supply of BTC @ 58000 to fill this order completely)
What is the difference from marketIOC and marketFOK then?
These two orders don’t require a specified price. They attempt to execute (under IOC and FOK logic respectively) without price limitations. In our previous example,
A limitIOC buy order with size = 10, price = 59000 will get filled with 2 BTC @ 58000, 4 BTC at 58100 and 2 BTC at 58200, and stop at that, as it can’t buy above 59000
A marketIOC buy order with size = 10, however, will get filled with 2 BTC @ 58000, 4 BTC at 58100, 2 BTC at 58200 and 2 BTC at 60000, never stopping until it gets filled completely or reaches the client’s trading limit
A marketFOK buy order with size = 3 will get filled with 2 BTC @ 58000 and 1 BTC at 58100
Before going live we strongly recommend to:
Provide a short integration document so we’re aware of your planned approach to integration and what methods you plan to use
Execute following scenarios on Test environment (see below)
Ensure prod-like activity over some period of time (e.g. several hours)
For Takers
Log in using the provided credentials
To obtain the Tradable Order Book, either
subscribe to Feed 'F' via Websocket API, or
request the POST api/book via Rest API
You will receive a snapshot of the specified order book with max 25 levels on each side: price & size.
Choose the instrument you are interested in
Try and make the first test trade using the “/add” command.
"clientOrderId": you can just use a timestamp
"price" & "size" can be taken from the order book you’ve just received
For Market Makers
Please refer to this scenario.
Yes, for testing in the demo environment, please, visit Request Demo page
Yes, the Platform supports REST and WebSocket APIs for both view-only and trading purposes.
Trade with no "last look" with our Firm Order Book
Improve the spread and the total cost of execution with our Aggregated Order Book
Automate your counterparty relationships, and reduce risk, all on one screen with our Risk-Management
Streamline position management with our Position Management
Trade now, settle later with Non-deliverable trading
Assign roles to your employees and control access to parts of the system with Multi-Roles
Stay in touch with your account activity with our Notification System
Personalize the price stream per taker with our Markups
Automate your post-trade settlements with our API
One report that will answer all of the bank's and regulator's questions
Defend against Toxic flow with our speed bump
Make data-driven decisions about your trading costs and the activity of your customers with Pulse