How trades are built

A trade in helixio starts from a market's standard terms and adds only what the two sides agreed. This page explains why booking works that way, why the counterparty you face changes the curve a trade discounts on, and how a confirmation from another system becomes the same kind of trade.

Templates and builders

Desks quote and book trades in each market's standard form. Both sides of a five-year SOFR swap already know it pays annually on ACT/360, starts two business days after the trade date, and pays two business days after each period ends. What they negotiate is the size, the side and the rate.

A template is that shared understanding, filed under a code. Asking it for a swap gives you a draft, a builder, that already carries every convention, and each with_* call states one of the terms the trade decided. So a booking says only what's particular to the trade, and two trades from the same template can't disagree on a convention by accident.

A trade's length comes in one of three forms: a tenor from spot ("5Y"), a forward tenor ("2Y3Y": starting two years after spot and running three), or an end date. Its rate is either stated or struck at par against a market, which makes the trade worth nothing on that market the moment it's booked. A draft with neither is refused rather than given a rate nobody chose. The calls are listed on templates and builders.

Collateral decides the discount curve

Most interbank trades are collateralised under a credit support annex (CSA) that names the cash collateral each side posts. Collateral earns the overnight rate of its own currency, so that rate is what a trade's cashflows are discounted at.

A USD swap facing a bank whose CSA posts EUR cash is funded at the EUR overnight rate, carried into dollars through the FX market. It therefore discounts on a different curve from the same swap under a USD CSA. Desks build that cross curve from FX swaps at the short end and cross-currency basis swaps beyond, and key it by both currencies: USD-CSA-EUR.

That's why a counterparty in helixio is an acronym and a CSA. Booking a trade facing a counterparty sets its discount key from the CSA; booking it facing no one uses the trade's own currency. The curve under that key is the market's to supply, so a counterparty never carries a curve itself. A desk keeps its counterparties in a master on the market and looks them up by acronym. The calls are listed on counterparties and CSA, and the steps are in book a trade with a CSA counterparty.

The registry

The registry maps each code to its template, and every template answers its family. A code is built from its market and its kind, such as USD-SOFR-OIS, BRL-USD-NDF or USD-GC-REPO, so it reads the way a desk names the contract. A code the registry doesn't hold is refused rather than matched to a neighbour: booking on the wrong market's conventions would be a quiet error that shows up only when the cashflows don't match. The listing is on the template registry.

Booking from FpML

Trades also arrive from outside: a trade capture system or a counterparty sends FpML confirmations, one trade per document or many. Reading one should book the same trade a template would, so the reader builds its legs coupon by coupon through the same constructors every other product uses.

Two choices follow from what a desk needs on a busy day. Every trade that can be read is booked, and what can't be read comes back as a refusal row beside the book, rather than one bad document stopping the rest. And an element that would change the economics but that the reader doesn't map is refused by name, never skipped: a silent default is the one answer a confirmation reader must not give. The steps are in book trades from FpML.

See also

• Templates and builders, the reference for drafting a trade.
• Counterparties and CSA, the reference for collateral.
• The template registry, every code by family.
• How a market is built, for the curves a discount key names.