Release Type: Informational – No immediate action required from platforms
Summary
The Zero Hash compliance team consistently monitors network risk. At times, platform customers may undergo enhanced due diligence (EDD) to authenticate the identity and/or transactional activity of the customer. Platforms may be asked to submit additional details about the end customer to Zero Hash for review via PATCH /participants/customers/:participantCode.
Zero Hash has added new fields to the participants database to accommodate EDD instances.
Action Required
No immediate action required from platforms.
Zero Hash contacts platforms directly if EDD information is required for submission.
Endpoints Impacted
PATCH /participants/customers/:participantCode – If EDD information is requested by the Zero Hash compliance team, it must be submitted to the PATCH endpoint. Note: You must also include <platform_updated_at> as per the PATCH endpoint guidelines.
POST /participants/customers/new – Platforms are not yet expected to pass EDD information when creating a participant; however as these fields (employment_status, industry, source_of_funds) are now a part of the Zero Hash participants database, platforms can expect to see the new fields included in the POST response with a null or unknown designation.
Release Type: Informational – Optional action from platforms
Summary
We have released the Transaction Fees feature to Production. Platforms configured to use this feature of the Convert Withdraw product will be able to specify the fees that were assessed on the order.
NOTE:
This feature is only offered to Platforms who use Zero Hash Liquidity Services. A future release will be made to open this up to our Trade Settlement (/trades) product.
We are adding a new endpoint called POST /convert_withdraw/rfq. It functions the exact same as the GET /convert_withdraw/rfq version. Both of them will continue to be supported indefinitely until stated otherwise. See 1-pager below, section “Flow” to see an example.
See dedicated 1-pager here for technical details, use cases, and more.
Action Required
If interested in the feature, please reach out to your Zero Hash representative.
Release Type: Informational – Optional action from platforms
Summary
We have released the Custom Spreads feature to Production. Platforms configured to use this feature of the Convert Withdraw product will be able to, on a per order basis, define the spread amount themselves programmatically. Previously, the spread configuration was only editable manually by a Zero Hash employee upon request.
NOTE:
This feature is only offered to Platforms who use Zero Hash Liquidity Services
We are adding a new endpoint called POST /convert_withdraw/rfq. It functions the exact same as the GET /convert_withdraw/rfq version. Both of them will continue to be supported indefinitely until stated otherwise. See 1-pager below, section “Flow” to see an example.
With this release, we also began exposing 2 new fields on the GET /trades and trades/:trade_id:
spread_notional: notional value of the spread applied, expressed in terms of the quoted_currency
spread_bps: basis point value of the spread applied
These fields are not only useful for Platforms who use the Convert Withdraw product, but any Zero Hash Liquidity Services products (excluding the Central Limit Order Book). For revenue reconciliation, Platforms can use these fields to determine the monthly amount of spread collected.
Action Required
If interested in the feature, please reach out to your Zero Hash representative.
Release Type: Informational – Optional action from platforms.
Summary
Zero Hash is enforcing Maximum and Minimum thresholds on our RFQ system. We have set our Maximum limit of 500,000 USD and a Minimum of 0.01 USD per quote. We have updated our error responses returned to Platforms if they are in breach of our Maximum or Minimum thresholds. If a Platform wishes to adjust this maximum, please email [email protected].
Action Required
Platforms must be prepared to handle the new status 400 error that is returned when a RFQ Maximum or Minimum has been breached.
Sample Response - Maximum limit breached
{
"errors": [
"unable to obtain quote, above maximum quote notional"
]
}
Release Type: Actionable – Platforms must share the configs to start using this feature.
Summary
It is possible to charge end customers fees to withdraw assets from their platforms to external wallets similar to traditional finance fees (wire fees, account closure fees, etc.). This is a separate configuration than the one used to manage custom spreads on liquidity quotes.
If enabled, a fee will be collected on every withdrawal execution and ledgered accordingly. The current feature works in NETTED (fixed sending amount) and ADDITIVE (fixed receiving amount) settings. Fee can be set in either a flat amount or spread (or both) per asset.
Action Required
To begin using this functionality, the following platform configurations must be set per ASSET with your Zero Hash team:
"withdrawal_spread_type": 'NETTED|ADDITIVE'
Netted deducts a fixed amount from the participant and any fees will be deducted from the quantity that is sent
Additive deducts the sending quantity in addition to any fees, so that the sending quantity is received by the destination wallet
"withdrawal_spread_fixed_fee": '0.000015'(This is defined in base currency and NOT in atomic units. So ETH and not WEI)
"withdrawal_spread_percentage_fee": '3'(This is in absolute % so here 3 means 3%)
"withdrawal_spread_platform_revenue_percentage": '60'(This is the revenue % based on agreement. In this scenario, the collected withdrawal fee account 60% to platform and 40% to ZH accounts)
Platforms using the Convert Withdraw product can now specify whether or not the network fee notional amount is included in the total notional amount or excluded. Examples:
Fee inclusive: A platform requests a quote by notional for an amount of 100 USD and the breakdown is (assuming a $2 network fee):
asset_cost_notional: $98
network_fee_notional: $2
total_notional: $100
Fee exclusive: A platform requests a quote by notional for an amount of 100 USD and the breakdown is (assuming a $2 network fee):
asset_cost_notional: $100
network_fee_notional: $2
total_notional: $102
Action required
There is a new optional Boolean query parameter called fee_inclusive that Platforms can use on the GET /convert_withdraw/rfq endpoint. A value of true means that the network fee is inclusive. A value of false or omitting this query parameter implies a fee exclusive-type call.
Actionable – If the platform uses non-documentary validation and has existing participants without required documents uploaded
Enhanced validation
Technical validation will be deployed such that any participant who has been verified using documentary verification must have a document uploaded to move to an approved status. See Summary below for additional details on the technical verification.
Please note that the technical logic now aligns with the existing Zero Hash compliance requirement. The compliance requirement is that when a customer is submitted to POST /participants/customers/new with an ID type that is not SSN, the underlying identification document must be uploaded via POST /participants/documents.
Existing participants
Any existing participants validated through documentary verification without the necessary document uploaded will automatically move to submitted status until such document is uploaded. When a document is uploaded for such an existing participant via POST /participants/documents, the participant can move to approved status.
If a Platform has impacted participants, Platform Solutions will send a list of affected participants to such Platform.
Summary
For customer verification, Zero Hash allows:
Documentary customer verification: ID types here – Required for non-US permanent residents (i.e., anyone who does not have an SSN). Also permitted for existing US customers who have already provided an identification number from a permissible official identification document, such as a passport or state driver’s license.
Non-documentary customer verification: SSN verification – Required for all US residents (with an SSN). Note: Platforms may still submit documentary evidence on top of SSN for these participants if they so choose.
Zero Hash has enhanced the technical logic and error handling around posting participants that have been verified using documentary verification. The technical logic now aligns with the existing Zero Hash compliance requirement that when a customer is submitted to POST /participants/customers/new with an ID type that is not SSN, the underlying identification document must be uploaded via POST /participants/documents.
Note that for US persons, non-documentary validation through SSN is permissible and no document is required to be uploaded.
Until a document is uploaded, the participant remains in a submitted state and is unable to make any requests (i.e., buy, sell, deposit, withdraw) until documents are posted. This logic upholds onboarding requirements for platforms and ensures participants missing necessary verification information are not advanced to approved.
Action required
It is an existing requirement that Platforms must ensure they are posting copies of a participant’s customer ID document that matches the identification (ID) number that was provided via POST /participants/customer/new. No document is required for non-documentary validation, currently only an SSN for US persons. Please note that the ID must be a permitted type.
Once Zero Hash receives the required documents, the participant will move to an approved state. More details on participant statuses here.
Endpoints impacted
If POST /participants/customers/new uses one of the following id_number_type, then an accompanying document is required to be submitted to POST /participants/documents:
us_drivers_license
us_passport
us_passport_card
us_permanent_resident_card
us_border_crossing_card
us_alien_card
us_id_card
non_us_passport
non_us_other
The only exception is SSN (considered non-documentary evidence). For id_number_type “ssn”, or if a U.S. tax_id (i.e., SSN) is submitted, there is no requirement to post a document.
Relevant documentation
API documentation regarding POST /participants/customers/new and POST /participants/documents
Related reminder (updated July 25, 2023)
Platforms also are reminded that as of September 5, 2023 (updated date), Zero Hash is implementing the enhanced “know your customer” or KYC format for all newly submitted retail Participant customers. This change was announced to Platforms on April 26, 2023.
As of September 5, 2023 (updated date), any new newly submitted participants whose application does not meet these standards will be declined.
Zero Hash now has the ability to apply different spreads per instrument (i.e., BTC/USD). Previously, only a default spread configuration existed. Now platforms have the ability to override this amount on a per-instrument basis.
Action Required
Please reach out to Zero Hash support if interested in using this feature as the configuration can only be made internally.
Informational – No action or changes necessary from platforms.
Summary
Zero Hash has updated our REST API to return all float and integers data types as a String. For more information on how to use our REST API to integrate with the Zero Hash Central Limit Order Book, please read our API specification Central Limit Order Book.
Endpoints impacted
The endpoint POST /orders/v1/search_orders will now return the parameters with the value represented as a string.
We will be implementing a change to improve performance related to settlement processing that requires the run_id field to migrate to a UUID "string" type.
On the REST API, the run_id field is currently being passed as type “string”, but appears as an integer (i.e., “123456”). We will be changing this to a UUID "string" type (i.e., “7f30ac2e-aa6d-4390-931a-2f947253722a”).
Additionally, on the Websocket Balances feed, the run_id is currently being passed as type “integer”. We will be changing this to a UUID "string" type.
Action required
Platforms need to adjust to make sure they support ingesting the run_id as a "string" instead of as an "integer". A specific use case that would be impacted would be if a platform is relying on the run_id integer to keep track of sequencing.
