> For the complete documentation index, see [llms.txt](https://initiativ.gitbook.io/initiativ/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://initiativ.gitbook.io/initiativ/mm_internal/4.-trading-mechanisms/4.4-otc-and-block-clear.md).

# 4.4 OTC and Block Clear

Block Clear is the facility for registering trades that were negotiated bilaterally, away from the order book, so they can be centrally cleared and settled like any on-book trade. Only trades at or above the block minimum for the product can be registered.

Once the CCP registers the trade, it becomes the counterparty to each side, so there is no residual bilateral counterparty risk.

## Minimum size

A registered trade must meet the block minimum for its product. Block minimums are set per product in the Contract Specification (Section 3.3) and revisited as markets develop.

## Submission and approval

At launch, trades are registered by a Broker, a User of a Broker Member, acting for two Members: the Broker submits the trade into Block Clear rather than entering it on the order book or through RFQ, in line with the permissions in Section 2.2. Only a Broker can submit a trade.

A Broker can submit trades only between Members that have authorised its Broker Member to act for them. It cannot name any other Member as a counterparty, and the Exchange rejects a submission for a Member that has not given that authorisation.

The submission carries:

* The instrument
* Price
* Quantity
* The two counterparties
* The time of the bilateral agreement

The Broker must submit the trade within a set time of the bilateral agreement. The time is set per product in the Contract Specification; a trade submitted later is rejected.

Each counterparty sees the Broker Member, not the other counterparty.

Both counterparties are notified and must approve the trade, reviewing instrument, price, quantity and time of agreement, within the approval window. The window starts when the trade is submitted; its length is set per product, and it ends at the latest at the end of the trading day. If either counterparty does not approve in time, the submission expires (Section 5.1).

If a counterparty identifies an error, it can reject the trade with a note visible to the Broker, who can then amend or cancel it. Any amendment resets approval for both sides.

## Validation and settlement

Before a registered trade executes, the Exchange checks that its price is reasonable against the market at the time of the agreement: the order book prices in the instrument or, where there are none, other relevant prices. The Exchange may reject a trade whose price falls outside that range.

The trade then passes the same pre-trade validation as any other trade, including the Trading Limit check on both counterparties for the full trade. If either side lacks sufficient Trading Limit, the trade cannot proceed, and neither side is shown the other’s limit. The full set of checks is described in chapter 6.

Once it executes, the trade goes to the CCP for registration like any other trade (Section 5.2) and settles on the same basis as the equivalent on-book instrument (chapter 9).

## Transparency and recordkeeping

Registered trades are published post-trade, separately from continuous order book volume, under the transparency rules that apply to the product, including any deferral (Section 8.3).

Counterparty identities are not disclosed between the two sides; only the Broker Member and the Exchange see both.

All registered trades are kept in the audit trail on the same recordkeeping and reporting basis as order book trades.
