Trade allocation

The analysis notes state the pending case most precisely. A pending trade sends no confirmation and does not settle, but it does flow to the trader's book, so the risk is managed from the start. The client's later allocations, amendments or netting requests replace it.

A break account is the controlled holding place for the same gap from the other side: Operations monitors how long trades sit there, and reports their age.

The blotter's Allocate (Split) action splits a block into child trades across clients, notionals or value dates. The user can:

• enter each child by hand;
• apply a saved allocation template, which fills in the split ratios;
• auto-split from a predefined template;
• submit the allocations to an ECN.

The analysis notes ask for auto-linking as well: given the ECN's specification, find the block automatically.

When a user starts a link from a block, the blotter restricts the eligible children by product:

The inter-desk transfer mechanics are those of deal netting, run in the other direction: Trade merge describes them.

• Risk. Unchanged for the firm: the allocations sum to the block.
• Counterparty. Changes. The block faces the dealing agent or the venue; each allocation faces its own fund or client. Credit, netting set and confirmation follow the allocation.
• Confirmation and settlement. The allocations confirm and settle; the block does not, from the moment it is allocated.
• Regulatory reporting. Each allocation is reported as a trade with an identifier of its own. How the block is reported depends on the regime and on whether it is allocated on the day.

The allocations must add up to the block exactly, for each currency amount. An allocation that would leave an unexplained remainder is rejected rather than reconciled approximately. The analysis notes on internal trades state the rule for netting and allocation together.

An allocation is an operation that attaches to a set of trades as a whole. Under trade sets and trade groups the set is a trade group and the run is its identity. The business needs the run in its own right:

• When and who. The time of the allocation, the user or process that made it, and any notes.
• How. The template applied, or the ECN message the allocation came from.
• What it did. The block, its children and any bridges, so the block's history lists its allocations and each child names its block.
• Correction. A wrong allocation is replaced as a whole: the old children are cancelled and a new allocation of the same block is made, which keeps the history of both.

This section is analysis rather than reported practice.

• The allocation. One row per allocation: the block, its source (manual, template, ECN or client request), the template where one was used, its time, who made it, and notes.
• Participation. One row per child and per bridge, with its role and its share of the block.
• One live allocation per block. A block has at most one current allocation. A re-allocation supersedes the previous one and records that it did.
• The no-residual rule. The children's amounts equal the block's amounts, checked before anything is written.
• Created together. The allocation, its participation rows, the children and the bridges are written in one transaction.
• The block stays. The block trade is not deleted or cancelled by the allocation. Its contribution to settlement and confirmation stops, which is a property of its allocated state rather than of its terms.

• Economic effect. The catalogue records no economic effect on the firm's risk, and notes that the counterparty moves to the allocations, which are then confirmed. Whether that makes allocation a trade event for the children is not settled.
• The block's end state. Whether an allocated block keeps its state and gains an "allocated" flag, or moves to a state of its own, decides how reports exclude it.
• Partial allocation. Whether a block may be allocated in stages, with the remainder held, conflicts with the no-residual rule unless the remainder is an explicit holding allocation.