> For the complete documentation index, see [llms.txt](https://docs.axis.to/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.axis.to/risk/venue-counterparty-risk.md). # Venue & Counterparty Risk Cross-venue arbitrage and other market-neutral strategies depend on venues and counterparties remaining available, solvent, liquid, and operational. Axis's venue-risk framework combines a tiered eligible universe, concentration constraints, continuous monitoring, and staged de-risking. See the full risk control policy: {% file src="/files/WIUsRmi0VDYYv0ePMupb" %} ## Direct venue exposure and exchange failure Exchange failure is a real and possible risk. Axis is transparent that its assets are **directly deposited on the venues themselves**, to run the strategy, liquidity has to sit on-venue rather than in a segregated off-exchange arrangement (see [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency.md)). If a venue becomes insolvent or freezes withdrawals, the assets held there are exposed. The nature of the strategy does, however, give Axis an unusually close view of its counterparties. Because trading requires **constant deposits and withdrawals**, Axis continuously tests and monitors each venue's withdrawal performance, liquidity, and solvency in the ordinary course of operating, not only through periodic reviews. That flow-level visibility feeds **strict per-venue exposure limits** set through a diligence, counterparty-risk-management, and risk-budgeting process, with continuous monitoring of how capital moves in and out. This continuous monitoring and the strict exposure limits are intended to **reduce** the probability and impact of a venue failure, they cannot eliminate it. Axis does not claim to always be first out of a failing venue, and managing a sudden, total exchange failure is inherently limited: withdrawals can stop without warning, and a large loss at a venue can exceed what monitoring or diversification can protect against. ## Control lifecycle 1. **Assess evidence.** Review security, regulatory status, financial health, reserve evidence, liquidity, operating history, and counterparty protections. 2. **Classify risk.** Assign a venue grade based on the evidence and relative risk. 3. **Apply limits.** Use the grade to determine eligibility and the maximum venue allocation. 4. **Monitor continuously.** Track withdrawal health, access changes, financial distress, liquidity, and operational incidents. 5. **Respond.** Reassess stable venues and reduce or exit exposure when conditions deteriorate. 6. **Reclassify before reuse.** Require a fresh risk decision before returning capital to a venue that was reduced or exited. ## Eligible, monitored, and active venues The venue framework distinguishes a broader classified universe, venues under operational monitoring, and a smaller active set. These categories are not interchangeable: classification does not mean capital is deployed, and monitoring does not mean a live position. ## Eligibility and concentration Venues are grouped into risk tiers that inform eligibility and concentration. The framework is intended to prevent venue selection from being based on yield alone and to limit the effect of any single failure. ### Grade-based venue caps A venue's grade sets the ceiling on how much of total AUM may be allocated to it. The caps are tiered by grade, the stronger the grade, the higher the permitted allocation: * **Grade A** carries the highest per-venue cap. Strongest security, regulatory, custody, reserve, liquidity, and operating profile. * **Grade B** carries a lower cap than Grade A. Strong liquidity and operations with additional compliance or concentration considerations. * **Grade C** carries a materially lower cap, with strategy-specific eligibility and enhanced monitoring for historical, regulatory, or concentration risks. * **Grade D** carries a minimal cap, used only where regulatory transparency or operating history is limited. These are per-venue maximums based on grade; the framework does not define a separate aggregate cap for all venues within the same grade. Most capital is intended for Grade A and B venues, while Grade C and D venues carry minimal exposure. New minting or rebalancing can temporarily move an allocation above its cap. The specific cap levels are illustrative internal targets rather than a published commitment. Venue grades, allocation caps, and operational limits can change as conditions change. ## Monitoring The venue-risk framework calls for continuous monitoring of: * withdrawal performance and transfer availability; * regulatory or access changes; * solvency and financial-distress indicators; * liquidity and market integrity; * operational incidents and abnormal venue behavior. The framework calls for KYC or equivalent onboarding of relevant venues and counterparties. ## De-risking and exit When risk deteriorates, the framework calls for staged de-risking and exit rather than assuming an immediate all-at-once withdrawal is always possible. ## Residual risk Monitoring can detect warning signs but cannot guarantee enough time to exit. Withdrawals can stop without notice, liabilities can be hidden, legal action can be sudden, and multiple venues can fail together. Diversification reduces concentration; it does not transform venue exposure into risk-free custody. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.axis.to/risk/venue-counterparty-risk.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.