# Risk Engine

{% hint style="info" %}
Operator and jurisdiction: BASIS is operated by BASIS DIGITAL INFRASTRUCTURE LTD, a Seychelles IBC (LEI: [254900IX2F2KCWNSSS64](https://lei.bloomberg.com/leis/view/254900IX2F2KCWNSSS64)).
{% endhint %}

The Risk Engine is the deterministic control layer that protects execution precision and structural alpha capture across the BASIS platform. It evaluates every proposed order before routing, monitors active positions after submission, and reconciles outcomes after completion.

It operates alongside BHLE, BASIS High-Load Execution, which provides sub-50μs internal decision latency, 100K+ OPS capacity, and proprietary routing infrastructure. No order reaches a venue unless it passes the engine's eligibility gate.

***

## 1. Design model: fail closed by default

The Risk Engine follows a default-deny model. Every trade begins in a rejected state and is promoted to approved only after all required checks succeed.

This fail-closed design matters for three reasons:

* Missing data results in rejection, not silent acceptance
* New or unclassified risk conditions do not bypass controls
* State transitions remain deterministic and auditable

{% hint style="warning" %}
If any required input is stale, unavailable, or internally inconsistent, the engine rejects the order and records the reason.
{% endhint %}

```
NORMAL
  -> pre-trade checks pass
  -> route order
  -> monitor fills and exposure
  -> reconcile balances and PnL
  -> NORMAL

NORMAL
  -> critical threshold breach
  -> BSCB
  -> DMM if automated recovery is insufficient
```

## 2. Eligibility gate

Before an order is submitted to any venue, the engine evaluates the following controls in sequence.

| Check                      | What is tested                                                                         | Failure action                               |
| -------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------- |
| System state               | Is the platform in `NORMAL` state, with no active BSCB or DMM restriction?             | Reject: system not in executable state       |
| Market data integrity      | Are reference prices, books, and internal signals fresh and internally consistent?     | Reject: invalid or stale market data         |
| Venue health               | Is the target venue reachable, responsive, and within latency bounds?                  | Reject: venue health check failed            |
| Venue allocation           | Would the order push venue concentration beyond the configured cap?                    | Reject: venue allocation limit reached       |
| Asset exposure             | Would net exposure to a single asset exceed policy limits?                             | Reject: asset concentration limit reached    |
| Margin sufficiency         | For leveraged legs, is there enough margin buffer above maintenance thresholds?        | Reject: insufficient margin buffer           |
| Impact estimate            | Is expected slippage and book impact within execution precision limits?                | Reject: estimated impact too high            |
| Structural alpha viability | After fees, expected slippage, and network costs, is the expected edge still positive? | Reject: expected edge not viable after costs |
| Reconciliation status      | Has the most recent reconciliation completed with no unresolved discrepancy?           | Reject: reconciliation lock active           |

## 3. In-flight monitoring

Once an order is live, the engine continues to supervise it in real time.

{% tabs %}
{% tab title="Positions" %}

* Margin health monitoring tracks open leveraged positions against warning and critical thresholds
* Hedge integrity checks verify that paired legs remain within allowed deviation bands
* Exposure drift checks detect inventory changes caused by partial fills, funding, or venue-side adjustments
  {% endtab %}

{% tab title="Orders" %}

* Fill monitoring cancels or replaces stale orders that remain open beyond expected timing windows
* Price protection prevents fills outside allowed impact bands during rapid market movement
* Venue response monitoring detects degraded acknowledgements, rejects, or out-of-order events
  {% endtab %}

{% tab title="Escalation" %}

* Warning thresholds trigger controlled reduction logic
* Critical thresholds trigger BSCB
* Repeated BSCB events, unresolved reconciliation errors, or non-automatable venue anomalies escalate to DMM
  {% endtab %}
  {% endtabs %}

## 4. Post-trade reconciliation

Every execution cycle ends with a mandatory reconciliation pass.

{% stepper %}
{% step %}

#### Balance verification

Venue balances are checked against the internal ledger. Any discrepancy is flagged immediately.
{% endstep %}

{% step %}

#### PnL attribution

Realized profit and loss is attributed to the originating strategy, venue, and execution path.
{% endstep %}

{% step %}

#### Cost accounting

Exchange fees, network fees, funding, borrow costs, and other direct execution costs are deducted from gross results.
{% endstep %}

{% step %}

#### State confirmation

The system confirms that all expected state transitions completed correctly before new exposure is permitted.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Reconciliation is not a reporting convenience. It is a hard risk control. If reconciliation does not complete cleanly, the engine can block new orders until the discrepancy is resolved.
{% endhint %}

## 5. Relationship to BSCB and DMM

The Risk Engine is the detection and decision layer. BSCB is the automated containment layer. DMM is the operator-supervised escalation layer for conditions that require discretionary review.

A practical hierarchy is:

* Risk Engine, detect and evaluate
* BSCB, contain automatically
* DMM, supervise recovery or exceptional handling

## 6. Why this matters

The BASIS risk model is built around deterministic execution, explicit mathematical constraints, and state machine risk controls. This architecture supports structural alpha capture without relying on permissive routing or manual intervention during normal operation.

In operational terms, the objective is simple:

* approve only what is safe to execute
* reject anything ambiguous
* reconcile every completed action
* escalate only through defined state transitions


---

# Agent Instructions: 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:

```
GET https://docs.basis.pro/technical-architecture/risk-engine.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.