A risk-limit reservation assigns part of a shared allowance to an in-flight instruction before its final outcome is known. Concurrent instructions need coordinated use of that allowance if the combined committed and reserved amount must remain within a limit.

Defining the shared invariant

An invariant states the condition the system must preserve across allowed state changes. For a simplified gross-notional limit, the condition is that committed use plus outstanding reservations does not exceed the configured allowance.

The amount, unit and population belong to the definition. A gross-notional allowance is different from a net market exposure or scenario-based risk measure. The calculation below assumes that each order consumes its full stated amount until an authoritative outcome changes that consumption.

A limit also needs an enforcement boundary. If two gateways share the same allowance, checking only each gateway’s private view does not establish the aggregate condition unless the design constrains how those views can diverge.

Two orders reading the same capacity

Take a 100-dollar allowance and two concurrent orders of 60 dollars each. Initially, no amount is reserved. Each order reads that initial state and independently determines that 60 dollars fits within 100 dollars.

If both decisions proceed without coordinated reservation, their combined reserved amount is 120 dollars. Each local comparison was arithmetically correct against the state it read; the aggregate outcome violates the defined invariant.

These are two different instructions. An idempotency key that prevents a retry of the first order from becoming a duplicate does not prevent the second distinct order from consuming the same apparent capacity.

Atomic reservations and bounded allocations

An atomic check-and-reserve operation evaluates available capacity and records the reservation as one protected state transition. Under the example’s limit, the first 60-dollar reservation leaves 40 dollars. The second 60-dollar request must then be denied, deferred or otherwise changed under the declared policy.

A shared transactional database can implement such a boundary when the schema, concurrency behavior and application logic preserve the invariant. Merely storing the requests in relational tables does not establish that result. PostgreSQL documents configurable isolation; the operation must be designed for the behavior actually selected.

Another constructed design allocates bounded portions of the allowance to separate gateways. If one gateway controls 40 dollars and another 60 dollars, and their local operations cannot exceed those allocations, the combined allocated capacity remains within 100 dollars. Unused capacity can be stranded at one gateway; moving it requires its own coordinated transition.

Fills, cancellation and release

A reservation persists according to the instruction’s lifecycle. A cancel request is evidence that cancellation was requested. Releasing all capacity before establishing the authoritative outcome can leave capacity available for reuse while the original order remains executable.

Fills, partial fills, rejected requests and confirmed cancellations therefore need distinct handling. Recovery must reconstruct committed use and remaining reservations from identifiable instructions and outcomes. A process restart does not reset the financial allowance consumed by already accepted work.

Scope of pre-trade controls

The example derives a concurrency requirement from a stipulated invariant. It does not prescribe one database isolation level, one distributed architecture or a universal legal control. Actual pre-trade controls depend on the institution, venue and risk measure.

What remains constant is the need to connect the aggregate limit to every instruction that consumes and releases it. Correct local checks establish the shared limit only when their coordination or allocation rules preserve that invariant.

Questions about transaction isolation

Does idempotency prevent two different orders exceeding one limit?

No. It handles repeated operations; different orders still need coordinated use of the shared allowance.

Does a relational database automatically enforce the risk limit?

No. The transaction boundary, isolation behavior and application invariant determine enforcement.

Can a cancel request immediately free the full reservation?

Only if the defined lifecycle and authoritative outcome establish that the reserved exposure can no longer occur. Sending the request alone does not establish that condition.