Ask us anything. We're here to help.

Institutional Exchange Integration Flow

The following is a specific integration flow for platforms using Zero Hash for agency-based settlement for institutional exchanges.

1. Participant Onboarding

1.1 Connecting with Customers

Onboarding of institutional participants, customers and counterparties requires manual KYC processes. You can submit the KYC information online via our portal, or via some other mutually agreed-upon process. Once the customer is onboarded, we will associate them with your exchange platform.

1.2 Viewing All Customers

Note: you must obtain the participant_code for each of your customers. You can do this a variety of ways:

1.2.1 Portal

You can review all of the participants you are associated with via the Parties page in the portal. Also, refer to the Participant Relationships and Access Rights page for more information on relationships.

1.2.2 Reports

You can review all of the participants listed as a customer_of_platform via the Platform Customers report in the Reports page in the portal

1.2.3 API

You can perform a GET /participants request to be provided a list of participants you are connected with. You can read more here: 

2. Client Funding

2.1 Deposits

Clients can initially fund their account through one of our banking partners for fiat or via one of their dedicated wallets for digital assets.

2.2 Allocations

Once funded, clients can allocate funds to various Zero Hash-integrated platforms. It's important to note that this type of movement will not produce an on-chain or inter-bank account movement. It will only take place on the Zero Hash ledger and gives the client trading power on different platforms. You can read about it more here.

Platforms can elect to lock assets once allocated to their platform. You can read about it more here.

2.3 Monitoring Client Funds

2.3.1 Email

When configured, platforms can receive email updates when clients balances change on their platform. 

2.3.2 Reports

Reports can be found in the Reports section of the portal. Here are the relevant options for client funding:

  • Platform Net Open Positions (NOP): Displays clients open positions with your platform.
  • Platform Net Delivery Obligations (NDO): Displays the amount that clients need to fund to clear trades that have been processed for settlement, but that could not be fully settled. Delivering the NDO balance will clear active and outstanding trades.
  • Platform Account Balances, Snapshot: Displays the current funding levels of all clients.
  • Platform Account Balances, Historical: Displays clients historical movements in and out of your platform.

2.3.3 API

You can perform a GET /accounts request and filter on account_owner = your customer’s participant_code to see how much they have in accounts dedicated for trading on your platform.

3. Trade Submission

Trade submission can be done via the standard Zero Hash FIX STP gateway, a custom FIX STP gateway or REST API.


Zero Hash operates a standard FIX STP gateway into which you can submit trades. Note: you must include the participant_code of the customers as tag 448 PartyID.

You can read more here:

3.2 Custom FIX Gateway

For specific engagements, Zero Hash can develop custom gateways to receive drop copies from third party trade feeds. This requires custom development work and mapping. Please contact if this is of interest.


You can submit trades via REST API via the POST /trades endpoint. Upon submission, and as a response you will receive a trade_id. This is the unique ID for the trade, useful in step 3.

You can read more here:

4. Trade Settlement

4.1 Settlement Schedules

We can process a trade for settlement according to a variety of schedule parameters, including:

  • Instant settlement
  • Repeated settlement attempts across any time interval
  • Batch settlement every day at a certain time

Further, we can configure a different schedule to retry settlement after the initial attempt, e.g. attempt to settle all new trades at 4pm CT and then retry every hour to settle outstanding trades.

For exchanges, we recommend batch settlement at 4pm CT each day, with a retry schedule that allows for delivery up to 24 hours later, i.e. first attempt at 4pm CT and retry until 4pm CT the next day.

4.2 Settlements

4.2.1 Portal

The Trades section of the portal allows you to view high-level information about trades that have been submitted to Zero Hash. The trade_state field will indicate whether a trade is:

  • accepted i.e. received but settlement has not yet been attempted
  • active i.e. received and settlement has been attempted, but the trade has not been fully settled or reached maturity
  • terminated i.e. the trade has concluded due to a full settlement, or a default

4.2.2 API

You will want to wait for the trade to settle before processing the withdrawal. So you can submit a GET /trades/ to see all trades and their status. You will want to see that the trade_state is terminated and the settlement_state is settled

You can read more here:

Optional validation: you can perform a GET /accounts request and filter on account_owner = your customer’s participant_code and you can see that they now have crypto in their account. But this can be safely assumed if the settlement_state is settled.

You can read more here: