Release date
Apr 4, 2023
Release type
Actionable – Responses returned from Zero Hash may impact user experience
Summary
Efforts to fight fraud and mitigate risk can result in decisions to remove participants from Zero Hash services. While Zero Hash has made these assessments and actions since inception, recent updates have improved the process internally and with platforms. Instead of severing end customer relationships with platforms, Zero Hash will now rely on participant status to determine availability of transactions.
New statuses and reason codes
Zero Hash has introduced new statuses that platforms may see when making requests. Flow states suggest that the participant would progress on to other states, and end states express finality of the state for the participant.
| Status | Description | State |
| locked | Investigative state | flow |
| pending_unlock | Preliminary investigations suggest that the risk is cleared and the participant may move back to approved | flow |
| pending_disable | Preliminary investigations suggest that the risk is confirmed and the participant should be permanently removed from Zero Hash | flow |
| disabled | Indefinite ban from Zero Hash | flow |
| divested | Participant was banned from Zero Hash, but balances still existed that were moved to the platform’s float account | end |
| closed | Participant was banned from Zero Hash, and no balances existed on the account | end |
Reason codes accompany status changes:
| Reason code | Description |
| compliance_issue | Unusual activity was detected and/or confirmed |
| user_request | Participant contacted Zero Hash or the platform to request that they be removed |
| risk_cleared | Investigations took place and the participant was cleared to be active again |
Action required
No specific action is required from platforms, but the following will impact transaction availability and you may receive errors when interacting with our API.
Blocked Transactions
If a request is made for a participant who is blocked from making the transaction, Zero Hash will respond with “Participant [participant_code] is not allowed to transact”.
GET /participants details
When reaching the <GET /participants> endpoint, platforms will notice expanded statuses (i.e. locked, disabled, etc.) and the addition of “reason_code”. Combinations of these fields infer varying transaction availability.
| Status | Reason code | Transaction availability |
| submitted | null | None - participant is awaiting initial approval |
| approved | null | All - participant was never under investigation |
| approved | risk_cleared | All - participant was under investigation but risk was cleared |
|
locked pending_unlock pending_disable |
user_request | Closing only (sell/withdraw) |
|
disabled divested closed |
user_request | None |
|
locked pending_unlock pending_disable disabled divested closed |
compliance_issue | None |
New endpoint
Platforms can now reach <POST /participants/customers/:participantCode/lock> only when a platform has completely terminated their relationship with a customer. This signals that the participant has been removed by the platform and allows the Zero Hash compliance team to conduct an appropriate risk-based investigation to determine if the participant should be disabled from Zero Hash services.
When reaching this endpoint, platforms must include “reason_code” and input either “compliance_issue” or “user_request”. Platforms can optionally include “notes” to provide more context on the lock, which can drastically speed up investigations on the Zero Hash side.
If Zero Hash determines the participant should be disabled, any remaining funds in the participant account may be remitted to the platform float, if legal to do so.
Sample request
POST /participants/customers/7PJM14/lock
{
"reason_code": "compliance_issue",
"notes": "confirmed fraud"
}
Sample response
Success
OK
Fail (e.g. participant status is not currently “approved” and therefore the participant cannot be locked)
{
"error": "error updating participant: participant action is not valid for participant current state"
Endpoints impacted
- All transactional endpoints will now reference participant status before allowing or denying the request
- GET /participants with expanded statuses and introduction of “reason_code”
- Introduction of new endpoint
<POST /participants/customers/:participantCode/lock>
Relevant documentation
Future release
Zero Hash is working to develop webhooks for Q3 to alert platforms when participant statuses change. Until then, platforms will be alerted to status changes either via API declines, or direct communications from the Zero Hash compliance team.