Trade merge
Table of Contents
1. Summary
A merge combines several trades into one trade, or into a small fixed number of trades. The contributors close and the result opens. Front-office systems call it aggregate, net or link net; this page uses merge, the term of the link catalogue, because "netting" already names the credit concept of netting sets and a payment mechanic.
A merge changes which trade the customer sees, so it is a trade event: the result is confirmed and the contributors are not. Where the contributors sit in different books, the merge also generates inter-desk transfers so that no book's risk moves. And a merge that would leave a residual is refused.
Each merge is one operation over a set of trades. The contributors, the result and the bridges are the roles its members play in one trade group, and the group carries a foreign key to the run that records when it ran and who ran it.
2. Detail
2.1. Kinds of merge
| Kind | Contributors | Result | Trigger |
|---|---|---|---|
| Execution netting | The fills of one execution algorithm | One ticket at the average rate | The execution ends |
| Scheduled netting | The fills of a hedging algorithm with no end time | Two tickets: the average of the buys and the average of the sells | A schedule, once or several times a day |
| Deal netting | Client trades of the same currency pair and value date | One net trade | A user, or a client's netting request |
| Expiry netting | Options expiring together | One net FX trade or one net cash flow | The expiry process |
| Premium netting | Premiums falling due together | One net cash flow | The expiry or payment process |
2.1.1. Execution and scheduled netting
The analysis notes on confirmations describe the case most clearly. When an execution algorithm finishes, all its fills are replaced by a single ticket at the average rate, and that ticket is the only deal confirmed with the client and the only one the client keys into its own system. A hedging algorithm has no end, so netting runs on a schedule and produces one ticket for the buys and one for the sells.
2.1.2. Deal netting
The blotter's Aggregate and Link Net actions combine selected trades of the same currency pair and value date into one net trade. The system checks that every selected trade is eligible before it proceeds; swaps are not eligible.
Where the contributors were booked in different spot books, combining them would change what each book holds. The analysis notes on internal trades state the rule: each contributing book's position must stay unchanged from the trader's point of view. Inter-desk transfers (IDTs) make it true:
- One IDT is generated per contributing trade, except where a book's position already matches the netted trade exactly.
- The IDT's counterparty is the spot book of the netted trade.
- Every such IDT is a spot.
- A netting that would leave a residual is rejected outright rather than reconciled approximately.
A client may also send netting requests against trades it booked as pending ahead of allocation. The resulting trades replace the originals.
2.1.3. Expiry and premium netting
When options expire together, their settlements can be netted. The notes describe three styles: no netting, net as FX — the settlements become one FX trade, possibly at a rate different from any strike — and net as cash for digitals and cash-settled options. A zero net FX amount generates no trade and no confirmation. Operations marks premium netting and expiry netting off in the authorisation queue.
Some trades are excluded from expiry netting by policy; the notes give American digitals, especially pay-at-hit, as the example. That operational "non-nettable" is a different attribute from the credit one.
2.2. What a merge does to its trades
| Role | What happens to the trade |
|---|---|
| Contributor | Closes. Its state moves to its end state, with the merge as the cause. |
| Result | A new trade, created by the merge. It is the one the customer confirms. |
| Bridge | An inter-desk transfer generated to keep a contributing book's risk unchanged. |
A merge is a trade event in the sense of trade links: the customer's agreement moves from the contributors to the result. Confirmations follows the trade population, not the message flow, which is why one confirmation covers the result of an execution merge.
2.3. How merge differs from its neighbours
| Neighbour | The difference |
|---|---|
| Compression | Compression removes offsetting risk across a portfolio, within tolerances, and may leave several replacement trades. A merge combines like trades into one result of the same kind. |
| Allocation | Allocation splits one trade into many; a merge combines many into one. They are inverse operations, and both use IDTs. |
| Settlement netting | Settlement netting pays several cash flows as one amount and changes no trade. A merge replaces trades. |
| Netting set | A netting set is a legal grouping for credit exposure. Its trades stay separate. |
2.4. Why a merge has an identity
A merge 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 merge, the user or process that ran it, and any notes.
- The policy. The kind of merge and, for expiry netting, the style.
- What it did. The contributors, the result and the bridges, so that a contributor's history says what replaced it and the result's history says what it came from.
- Undo. A merge done in error must be undone as a whole: the result and the bridges cancelled and the contributors restored together.
Pairwise links cannot carry any of these for a merge of twenty fills into one ticket with five bridges.
2.5. What follows for the model
This section is analysis rather than reported practice.
- The merge. One row per merge: its kind, its policy, its time, who ran it, and notes.
- Participation. One row per trade the merge touched, with its role: contributor, result or bridge. A merge has at least two contributors and, except for a zero expiry net, at least one result.
- The no-residual rule. The contributors' amounts must equal the result's amount for each currency, with the bridges accounting for each book's share. The check runs before anything is written.
- Created together. The merge, its participation rows, the contributors' state changes, the result and the bridges are written in one transaction.
- Undo. An undo is a second merge-kind act that references the first and reverses it; the first is never deleted.
2.6. Open questions
- Contributor end state. Whether a merged contributor is cancelled, or terminated with merge as the cause, decides which reports still see it. The execution case reads as a cancellation, because the client never confirmed the fills.
- Eligibility rules. The notes give same currency pair and value date for deal netting, and exclude swaps. The full rule per product type is not written down.
3. Sources
The kinds of merge, the confirmation consequences, the IDT mechanics, the no-residual rule and the expiry netting styles are drawn from internal analysis notes on confirmations and versioning, internal trades, the trade blotter and netting sets. The model consequences are this page's own analysis.
4. See also
- Trade — the structure note that orders this cluster.
- Trade sets and trade groups — why a merge is a group with an identity.
- Trade allocation — the inverse operation.
- Trade compression — the portfolio-wide relative.
- Netting sets — the credit sense of netting.
- Confirmations — which trade the customer confirms.
- Trade Blotter — Aggregate / Net and Link Net.
- Knowledge — the hub of all knowledge notes.