Confirmations

A confirmation is a legal document, not a report. The CFTC defines confirming as the consummation of legally binding documentation that memorializes the agreement of the parties to all terms of a swap, and requires that a confirmation be in writing and that it legally supersede any previous agreement. Under the ISDA Master Agreement the parties exchange documents and other confirming evidence, each a Confirmation, and each Transaction is evidenced by one.

Three properties follow, and each has a system consequence.

1. The confirmation supersedes what came before. A new confirmation replaces the previous one; it does not accumulate.
2. It is bilateral. Both parties hold the same document, and both can enforce it.
3. It is the record of the terms, not of the trade. A trade can exist unconfirmed; it cannot settle unconfirmed.

Three steps sit between an execution and a confirmed deal, and the words are not interchangeable. All three are bilateral; the internal check that precedes them is operational authorisation.

The CFTC defines the first and third. An acknowledgment is "a written or electronic record of all of the terms of a swap signed and sent by one counterparty to the other"; a confirmation is "legally binding documentation that memorializes the agreement of the counterparties to all of the terms of a swap transaction".

It defines no step called verification, and the word is used in the industry for both the internal check and a bilateral one. This corpus therefore avoids it. Operational Authorisation records the ambiguity.

Affirmation is not confirmation, and a platform makes the difference easy to miss. DTCC Deriv/SERV ran an affirmation service, AffirmXpress, in which a counterparty reviewed a broker's trade details and affirmed or queried them, and an affirmed trade could flow automatically to the matching and confirmation service "resulting in legal confirmation within seconds of affirmation". The affirmation was the trigger; the confirmation was the legal act.

Ageing separates the internal check from the bilateral ones. An unauthorised trade is an internal control exception, and operational authorisation covers it. An unconfirmed trade is a counterparty risk, because the terms are not yet enforceable in the form the parties agreed.

The steps above are its transitions. The internal check that precedes them belongs to the trade lifecycle as authorisation.

not_required has no transitions out. An intra-entity transfer, a test booking or a hypothetical enters it at booking and stays there, which states positively that confirmation was never owed rather than leaving a reader to infer it from an absent value. Trade classification decides which trades those are.

No other state is terminal either. A confirmed trade returns to unconfirmed whenever a confirmable amendment moves the external version, which is why confirmation is stated as of a version rather than once and for all. Trade versioning covers the versions themselves, and trade activity which amendments are confirmable.

When the trade expires or is cancelled this lifecycle simply stops. The status keeps its last value, which still records whether the trade was ever confirmed.

Confirmation backlogs were an operational risk long before they were regulated. The 2005 ISDA Novation Protocol existed to clear a backlog that was largely novation-driven, and both major regimes now set deadlines of their own.

• In the United States, CFTC rule 17 CFR 23.501 requires a swap dealer or major swap participant to have written procedures to execute a confirmation for each swap, with time limits that depend on the counterparty type and the asset class. Subpart I of Part 23 also covers portfolio reconciliation (23.502), portfolio compression (23.503) and swap trading relationship documentation (23.504).
• Also in the United States, 17 CFR Part 45 separates primary economic terms data from confirmation data. Primary economic terms are the terms the counterparties match or affirm when they verify a swap; confirmation data are the terms they match and agree when they confirm it. Both must reach a swap data repository, on a schedule tied to the confirmation.
• In the European Union, EMIR Article 11(1) requires procedures for timely confirmation of non-cleared OTC derivative contracts, and Article 12 of the risk mitigation RTS, Commission Delegated Regulation (EU) No 149/2013, sets the deadlines: T+1 for credit and interest rate derivatives between financial counterparties, T+2 for equity, FX and commodity derivatives, and longer windows where one party is a non-financial counterparty below the clearing threshold. Article 12(4) adds a monthly reporting duty for unconfirmed trades outstanding more than five business days.

The European Commission has stated that the deadlines require procedures that enable confirmation within the period, and are not hard deadlines in themselves. The practical reading is the same either way: a trade that ages past its deadline is an exception that must be counted, explained and cleared.

The events that raise a confirmation:

The list is not a list of trade events. It is the subset of trade events that change the terms the customer has agreed to, or that the deal itself requires the customer to acknowledge in writing.

Events that are not on the list are not confirmed: authorisation states, internal book moves, netting and settlement mechanics, market fixings the contract already provides for, and annotations such as hedge links and user-defined links. Trade Structures and Deal Composition carries the full table of linkages and marks which ones have an economic effect.

A structure is confirmed as a whole when the parts have no independent existence to the customer. The test is not the size of the deal, it is the typeness:

• A structure whose legs exist only as parts of the deal confirms as one document. A partial close-out of such a deal produces one confirmation for the remainder, not one per leg.
• A package of trades that the customer holds under its own terms per trade confirms trade by trade, even though the trades were executed together.

Netting complicates the picture, and the rules depend on the cause. An execution algorithm produces many fills that collapse to one ticket, so one confirmation covers the lot. A scheduled netting under a hedging programme produces one confirmation per netting date. In both cases the confirmation follows the trade population, not the message flow.

A trade must be in the population before it can receive events. The population is a state machine, and the states track the confirmation steps above: captured, acknowledged, affirmed, confirmed. The states are not decoration. Each one gates a different capability, and the useful implementation reads the gate rather than re-deriving the state at each call site.

Confirmation intent is a property of the trade, not of a separate workflow. A message that carries a trade therefore carries, alongside the terms:

• The intent to confirm, and whether that intent is active.
• The authorisation state and the actor who set it.
• The event timestamps, at the precision the matching service needs.
• The identifiers, long and short, so the receiving system can match the trade to its own record.
• The eligibility of the trade for transaction reporting.
• The version the message confirms.

The last item is the one most often dropped, and it is the one that makes reconciliation possible. A confirmation that does not name the version it confirms cannot be matched against the customer's record.

The confirmed document and the booked trade are related but not identical. Confirmations are often enriched by hand while they are drafted, because the legal text carries terms the booking system does not hold: governing law, additional representations, and the settlement and account details the two parties have agreed.

Two consequences:

• The confirmation is a document with a life of its own. It is stored, versioned and retrieved as a document, not regenerated on demand.
• Reconstructing the booked trade from the confirmation is not guaranteed, and reconstructing the confirmation from the booked trade is not either. The link between them is the trade identifier and the version.

Settlement instructions are the common case of a term that lives on the confirmation more than on the trade. See Standing Settlement Instructions.

We have the versioning primitives and we do not yet have the confirmation model.

The two-version rule above has a counterpart in state. Trade lifecycle carries a confirmation lifecycle whose states are unconfirmed, queried, affirmed and confirmed, moving on the external version exactly as this rule describes, alongside a trade lifecycle that moves on the internal version. The steps distinguished above are transitions in the confirmation lifecycle; the internal check that precedes them is operational authorisation, a transition in the trade lifecycle.

What exists:

• Reference data versions a composite by touching the parent when a child changes, so "as of version N" is a temporal window join. See Temporal Composite Entity Versioning: Target State.
• Trading does not adopt that design. Each entity versions on its own timeline and the composite read is a temporal join over keys.
• The blotter exposes the deal actions that produce versions: Amend, Cancel, Clone and Roll Forward. See Trade Blotter.

What is missing, and what development should add:

1. An external version, distinct from the internal version, and bumped only by a change to the customer's terms.
2. Authorisation recorded as trade metadata, never as a version cause.
3. One activity record per version, carrying the cause, with a stated priority order when several causes coincide.
4. A confirmable flag derived from the amend classification, not inferred from the presence of a value change.
5. Undo events that post a mirror version and never delete one.
6. The confirmed version stamped on every outgoing confirmation message.

• CFTC, 17 CFR Part 23 Subpart I, Swap Documentation (confirmation, portfolio reconciliation, compression, relationship documentation): https://www.law.cornell.edu/cfr/text/17/part-23/subpart-I
• CFTC, 17 CFR 45.1 definitions: primary economic terms data, confirmation data, life cycle event: https://www.govinfo.gov/content/pkg/CFR-2013-title17-vol1/pdf/CFR-2013-title17-vol1-sec45-1.pdf
• EMIR, Article 11, risk mitigation techniques for non-cleared OTC derivative contracts: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32012R0648
• Commission Delegated Regulation (EU) No 149/2013, Article 12, timely confirmation: https://www.legislation.gov.uk/eur/2013/149/chapter/VIII/adopted
• ESMA, Questions and Answers on EMIR implementation: https://www.esma.europa.eu/sites/default/files/library/esma70-1861941480-52_qa_on_emir_implementation.pdf
• DTCC Deriv/SERV AffirmXpress (archived product page): https://web.archive.org/web/20071105023716/http://www.dtcc.com/products/derivserv/suite/affirmxpress.php
• FpML 5.10, Messaging Framework (confirmation and trade change messages): https://www.fpml.org/docs/FpML5-messaging-framework-2.pdf
• FpML 5, post-trade events (amendment, increase, termination, novation): https://cdn.fpml.org/spec/fpml-5-11-7-rec-1/html/confirmation/schemaDocumentation/schemas/fpml-business-events-5-11_xsd/groups/PostTradeEventsBase.model.html
• ISDA Common Domain Model, Event Model (a lifecycle event as atomic primitive instructions over trade states): https://cdm.finos.org/docs/6.0.0/event-model/
• EMTA, NDF template terms and FX market practice: https://www.emta.org/
• Foreign Exchange Committee, Master Confirmation Agreement for Non-Deliverable Forward FX Transactions, Practice Notes: https://resources.newyorkfed.org/medialibrary/microsites/fmlg/files/documentation/practicenotes.pdf