Use case · Post-trade operations
One trade entity, regulator-ready history
Trade settlement is not a straight line. Validation, matching, affirmation, instruction, repair, settlement, failure, and cancellation are all operationally and often regulatorily significant events — and in T+1 environments, each exception increases reporting pressure. Cyoda models the full post-trade lifecycle as a single TradeSettlement entity with an explicit entity workflow: named states, criteria-driven transitions, attached processors, and an immutable history of every step on that entity.
Point-in-time reconstruction of any trade at any historical timestamp is a query against entity history — not a warehouse rebuild, not an ETL pipeline, not a separately maintained audit copy.
The problem
Settlement operations don't fit a status column
Matching and affirmation are not cosmetic steps. A trade can match on economics but fail on settlement instructions — triggering an exception path with its own operational state, its own process attachments, and a repair loop that must re-enter the main lifecycle. That branching and loop-back cannot be modelled without losing the history of the original failure.
Affirmation is a regulatory checkpoint in modern post-trade flows. Whether a trade was affirmed before the affirmation deadline, and what state it was in when it was instructed to the custodian, are questions regulators ask. The answers must come from the system of record, not from a separately assembled report.
Settlement failures and cancellations add further branching. Each is a terminal or repair path with its own regulatory reporting requirement. In conventional stacks, these paths live in different systems — the orchestration engine handles progression, the database holds state, the event log holds history, and a separate warehouse or ETL process assembles the view regulators see.
The seams between those systems are where consistency breaks — and where reconciliation cycles, reporting lags, and audit gaps originate.
The conventional assembly
Status column in the trade database
Cannot model repair loop-back or exception branching without losing the history of prior state.
Separate orchestration engine
Different consistency boundary from the database — entity state and lifecycle progression can diverge; reconciliation required.
Event log or message broker
Eventual consistency — operational state and event history are not guaranteed to agree at any given timestamp.
Warehouse or ETL layer for reporting
Regulatory reconstruction depends on copied data. Any pipeline lag means the regulatory view can be stale or incomplete.
Glue code across all of the above
Outbox patterns, idempotency guards, and reconciliation jobs are required to hold the assembly together.
How you can model it with Cyoda
TradeSettlement entity workflow in a settlement system
Each trade is a Cyoda TradeSettlement entity. Its lifecycle is modelled as an entity workflow graph with named states, criteria-guarded transitions, attached processors, exception branches, repair loop-backs, and immutable history on the entity itself. The graph below shows one way the full post-trade lifecycle could be modelled with the append-only record created by those entity transitions.
ENTITY WORKFLOW
TradeSettlement
Lifecycle in a settlement system
Pan to explore the entity lifecycle and select a state or transition for details.
Entity lifecycle detail
Select a state or transition to inspect the entity lifecycle semantics.
TradeSettlement entity workflow JSON
This viewer is driven directly from the supplied TradeSettlement entity workflow file, including exception branches, repair loop-backs, and terminal outcomes.
What the entity contains
This illustrative StructuredTrade example uses a more realistic settlement model: identifiers, rates product terms, counterparties, confirmation and clearing status, settlement instructions, projected cashflows, regulatory reporting, workflow transitions, controls, and immutable audit state all live on the same governed entity record.
TradeSettlement.json
{
"entityType": "StructuredTrade",
"entityId": "TRADE-IRS-2026-00018472",
"version": 17,
"currentState": "SETTLEMENT_PENDING",
"businessContext": {
"useCase": "Corporate loan hedging",
"frontOfficeBook": "USD_RATES_CORP_HEDGING",
"tradingDesk": "USD Rates Swaps",
"region": "US",
"sourceSystem": "Murex",
"bookingTimestamp": "2026-04-28T14:07:32Z"
},
"tradeIdentifiers": {
"internalTradeId": "MX-IRS-8842197",
"uti": "5493006MHB84DD0ZWV18IRS2026042800018472",
"priorUti": null,
"clearingHouseTradeId": "LCH-IRS-98277164",
"confirmationId": "CONF-20260428-778203",
"portfolioCompressionGroupId": null
},
"product": {
"assetClass": "RATES",
"productType": "INTEREST_RATE_SWAP",
"subType": "VANILLA_FIXED_FLOAT",
"clearingEligibility": "MANDATORY_CLEARING",
"settlementType": "CASH_SETTLED_PERIODIC_PAYMENTS",
"documentation": {
"masterAgreement": "ISDA_2002",
"definitions": "ISDA_2021_INTEREST_RATE_DERIVATIVES_DEFINITIONS",
"confirmationMethod": "ELECTRONIC_MATCHING"
}
},
"tradeDates": {
"tradeDate": "2026-04-28",
"effectiveDate": "2026-04-30",
"terminationDate": "2031-04-30",
"firstPaymentDate": "2026-07-31",
"finalPaymentDate": "2031-04-30",
"businessCenters": [
"USNY",
"GBLO"
],
"businessDayConvention": "MODIFIED_FOLLOWING"
},
"parties": [
{
"partyId": "BANK_EXEC_ENTITY",
"role": "EXECUTING_BROKER",
"name": "Example Bank NA",
"lei": "5493006MHB84DD0ZWV18",
"settlementRole": "PAYER_FIXED_RECEIVER_FLOAT"
},
{
"partyId": "CORPORATE_COUNTERPARTY",
"role": "CLIENT_COUNTERPARTY",
"name": "Northstar Manufacturing Inc.",
"lei": "8I5DZWZKVSZI1NUHU748",
"settlementRole": "RECEIVER_FIXED_PAYER_FLOAT"
},
{
"partyId": "LCH_SWAPCLEAR",
"role": "CENTRAL_COUNTERPARTY",
"name": "LCH Ltd",
"lei": "549300EXV10C0I8T3O18"
},
{
"partyId": "CLEARING_BROKER",
"role": "FUTURES_COMMISSION_MERCHANT",
"name": "Example Clearing LLC",
"lei": "213800WAVVOPS85N2205"
}
],
"economics": {
"notional": {
"amount": 150000000,
"currency": "USD",
"amortization": "NONE"
},
"payerReceiver": {
"fixedRatePayer": "BANK_EXEC_ENTITY",
"floatingRatePayer": "CORPORATE_COUNTERPARTY"
},
"fixedLeg": {
"legId": "FIXED-LEG-1",
"payerPartyId": "BANK_EXEC_ENTITY",
"receiverPartyId": "CORPORATE_COUNTERPARTY",
"fixedRate": 0.0345,
"rateNotation": "DECIMAL",
"dayCountFraction": "30/360",
"paymentFrequency": "SEMI_ANNUAL",
"calculationPeriodFrequency": "SEMI_ANNUAL",
"paymentRelativeTo": "CALCULATION_PERIOD_END_DATE",
"stubPeriod": "NONE"
},
"floatingLeg": {
"legId": "FLOAT-LEG-1",
"payerPartyId": "CORPORATE_COUNTERPARTY",
"receiverPartyId": "BANK_EXEC_ENTITY",
"floatingRateIndex": "USD-SOFR-COMPOUND",
"indexTenor": "OVERNIGHT",
"spread": 0.00125,
"spreadBps": 12.5,
"dayCountFraction": "ACT/360",
"paymentFrequency": "QUARTERLY",
"calculationPeriodFrequency": "QUARTERLY",
"resetFrequency": "DAILY",
"compoundingMethod": "OVERNIGHT_COMPOUNDED",
"lookbackDays": 2,
"rateCutOffDays": 0,
"paymentRelativeTo": "CALCULATION_PERIOD_END_DATE",
"stubPeriod": "NONE"
}
},
"valuationSnapshot": {
"valuationDate": "2026-04-30",
"currency": "USD",
"cleanPresentValue": -1248500.42,
"accruedInterest": 0,
"dv01": 72134.89,
"collateralAgreement": "CSA_2016_VM_ONLY",
"marginCallRequired": true,
"initialMarginModel": "SIMM",
"variationMarginCurrency": "USD"
},
"confirmation": {
"status": "MATCHED",
"matchedAt": "2026-04-28T15:18:44Z",
"matchingPlatform": "MarkitWire",
"matchedFields": [
"notional",
"currency",
"effectiveDate",
"terminationDate",
"fixedRate",
"floatingRateIndex",
"spread",
"paymentFrequency",
"dayCountFraction",
"businessDayConvention"
],
"exceptions": []
},
"clearing": {
"cleared": true,
"clearingHouse": "LCH_SWAPCLEAR",
"clearingStatus": "ACCEPTED",
"submittedAt": "2026-04-28T15:24:03Z",
"acceptedAt": "2026-04-28T15:24:29Z",
"originalBilateralTradeId": "TRADE-IRS-2026-00018472",
"novationEventId": "EVENT-CLRG-20260428-000392",
"resultingClearedTradeIds": [
"LCH-IRS-98277164-BANK",
"LCH-IRS-98277164-CLIENT"
]
},
"settlement": {
"settlementStatus": "PENDING_CASHFLOW_RELEASE",
"settlementCurrency": "USD",
"nettingSetId": "CSA-USD-RATES-NS-00481",
"standardSettlementInstructions": [
{
"partyId": "BANK_EXEC_ENTITY",
"cashAccountId": "SSI-USD-JPM-001",
"bic": "CHASUS33",
"accountNumberMasked": "****63001",
"custodian": "JPMorgan Chase Bank",
"currency": "USD",
"validated": true,
"lastValidatedAt": "2026-04-25T09:11:00Z"
},
{
"partyId": "CORPORATE_COUNTERPARTY",
"cashAccountId": "SSI-USD-GS-009",
"bic": "GSJBUS33",
"accountNumberMasked": "****45009",
"custodian": "Goldman Sachs Bank USA",
"currency": "USD",
"validated": true,
"lastValidatedAt": "2026-04-24T16:40:00Z"
}
],
"nextSettlementInstruction": {
"paymentDate": "2026-07-31",
"netPaymentAmount": 846875,
"currency": "USD",
"payerPartyId": "BANK_EXEC_ENTITY",
"receiverPartyId": "CORPORATE_COUNTERPARTY",
"cashflowIds": [
"CF-FIXED-20260731",
"CF-FLOAT-20260731"
],
"releaseStatus": "AWAITING_RATE_FINALISATION"
}
},
"cashflows": [
{
"cashflowId": "CF-FIXED-20260731",
"legId": "FIXED-LEG-1",
"calculationPeriodStartDate": "2026-04-30",
"calculationPeriodEndDate": "2026-07-31",
"paymentDate": "2026-07-31",
"payerPartyId": "BANK_EXEC_ENTITY",
"receiverPartyId": "CORPORATE_COUNTERPARTY",
"notional": 150000000,
"rate": 0.0345,
"dayCountFraction": "30/360",
"accrualFactor": 0.25,
"amount": 1293750,
"currency": "USD",
"status": "PROJECTED"
},
{
"cashflowId": "CF-FLOAT-20260731",
"legId": "FLOAT-LEG-1",
"calculationPeriodStartDate": "2026-04-30",
"calculationPeriodEndDate": "2026-07-31",
"paymentDate": "2026-07-31",
"payerPartyId": "CORPORATE_COUNTERPARTY",
"receiverPartyId": "BANK_EXEC_ENTITY",
"notional": 150000000,
"index": "USD-SOFR-COMPOUND",
"observedRateStatus": "PARTIALLY_OBSERVED",
"projectedCompoundedRate": 0.02855,
"spread": 0.00125,
"allInRate": 0.0298,
"dayCountFraction": "ACT/360",
"accrualFactor": 0.255556,
"amount": 446875,
"currency": "USD",
"status": "AWAITING_FINAL_FIXING"
}
],
"regulatoryReporting": {
"reportingRegime": "CFTC_PART_43_45",
"reportingPartyId": "BANK_EXEC_ENTITY",
"reportingStatus": "ACKNOWLEDGED",
"sdr": "DTCC_DDR",
"lastReportedAt": "2026-04-28T15:31:12Z",
"actionType": "NEWT",
"eventType": "CLRG",
"reportedFields": {
"uti": "5493006MHB84DD0ZWV18IRS2026042800018472",
"assetClass": "RATES",
"productType": "InterestRateSwap",
"notionalCurrency": "USD",
"notionalAmount": 150000000,
"cleared": true,
"centralCounterparty": "LCH_SWAPCLEAR"
},
"exceptions": []
},
"workflow": {
"stateMachine": "StructuredTradeSettlementWorkflow",
"currentState": "SETTLEMENT_PENDING",
"allowedTransitions": [
{
"event": "FINAL_RATE_FIXING_RECEIVED",
"targetState": "CASHFLOW_READY_FOR_APPROVAL"
},
{
"event": "SETTLEMENT_EXCEPTION_RAISED",
"targetState": "SETTLEMENT_EXCEPTION"
},
{
"event": "TRADE_CANCELLED",
"targetState": "CANCELLED"
}
],
"completedTransitions": [
{
"event": "TRADE_CAPTURED",
"fromState": "NEW",
"toState": "VALIDATION_PENDING",
"timestamp": "2026-04-28T14:07:33Z",
"actor": "MurexAdapter"
},
{
"event": "ECONOMICS_VALIDATED",
"fromState": "VALIDATION_PENDING",
"toState": "CONFIRMATION_PENDING",
"timestamp": "2026-04-28T14:08:12Z",
"actor": "TradeValidationService"
},
{
"event": "CONFIRMATION_MATCHED",
"fromState": "CONFIRMATION_PENDING",
"toState": "CLEARING_PENDING",
"timestamp": "2026-04-28T15:18:44Z",
"actor": "MarkitWireAdapter"
},
{
"event": "CLEARING_ACCEPTED",
"fromState": "CLEARING_PENDING",
"toState": "SETTLEMENT_PENDING",
"timestamp": "2026-04-28T15:24:29Z",
"actor": "LchClearingAdapter"
}
]
},
"controls": {
"validationResults": [
{
"ruleId": "IRS-001",
"description": "Effective date must be after trade date",
"result": "PASS"
},
{
"ruleId": "IRS-007",
"description": "Cleared USD SOFR swap must reference supported overnight compounding conventions",
"result": "PASS"
},
{
"ruleId": "SSI-003",
"description": "Settlement instructions must be current and currency-compatible",
"result": "PASS"
},
{
"ruleId": "REG-014",
"description": "UTI must be present before regulatory submission",
"result": "PASS"
}
],
"makerChecker": {
"requiredForManualAmendment": true,
"lastApproval": {
"approvalId": "APPROVAL-20260428-00491",
"approvedBy": "rates-ops-supervisor@examplebank.com",
"approvedAt": "2026-04-28T14:11:03Z",
"reason": "New cleared client swap booking validated"
}
}
},
"exceptions": [],
"audit": {
"createdAt": "2026-04-28T14:07:33Z",
"createdBy": "MurexAdapter",
"lastUpdatedAt": "2026-04-30T09:42:18Z",
"lastUpdatedBy": "SettlementWorkflowService",
"immutableEventCount": 42,
"lastEventId": "EVENT-SETTLEMENT-20260430-001126"
}
}
Criteria guard every transition
MATCHED to AFFIRMED only fires when the match criterion evaluates to true. INSTRUCTED to SETTLED requires the settlement confirmation criterion. Criteria are part of the entity workflow definition, not application code.
Exception paths are named states
REPAIR_REQUESTED and MANUAL_REVIEW are explicit states with their own criteria and attached processes. The repair loop back to VALIDATING is a first-class transition, not a flag reset.
Processes attach to transitions
Matching logic, custodian instruction dispatch, and regulatory publication attach to the transitions that trigger them. They run inside the entity transaction boundary, not as background jobs.
Illustrative example only. These examples show how a system could be modelled with Cyoda. They are not detailed business requirements or prebuilt Cyoda application templates.
The outcome
What changes when history is native
Immutable transition log by default
Every state change — matched, repair-requested, affirmed, settled — appends a signed, timestamped record. No separate audit table to synchronise; immutability is an invariant of the write path.
Point-in-time reconstruction is a query
Because history is native to the entity, the state of any trade at any moment is reconstructable from the stored transitions. No warehouse rebuild, no log replay, no ETL dependency.
Exception paths stay inside the lifecycle
Repair, affirmation failure, and settlement fail are named states with criteria-guarded transitions and attached processes — not side-system logic that has to be correlated after the fact.
Operational reporting runs on transactional history
Trade-state distribution, exception rates, and settlement latency are queryable from the same model that governs the entity lifecycle. There is no copied data to drift.
Write conflicts handled at platform level
Concurrent transitions to the same entity are resolved at the Cyoda platform level. Settlement race conditions and duplicate instruction delivery do not require application-level guards.
No ETL seam between system of record and regulator
Regulatory reconstruction queries entity history directly. The record the regulator sees is the same record that governed the operational entity lifecycle — no transformation layer in between.
In production
Why this matters for post-trade operations
The architectural difference between native history and assembled history becomes operationally significant under regulatory scrutiny, during exception-heavy periods, and at the scale where reconciliation costs compound.
Regulator and audit readiness
MiFIR, EMIR, and CAT all require the ability to reconstruct trade state at specific timestamps. When history is a first-class property of the entity, that reconstruction is a platform capability — not a reporting pipeline you have to build and maintain.
Lower exception-handling overhead
SSI mismatches, matching failures, and affirmation delays each open an exception path. Keeping those paths inside the entity workflow — as named states with criteria and processors — means exception state is always visible, always auditable, and never lost in a side system.
Fewer reconciliation cycles
When an orchestration engine, transactional database, event log, and audit trail are separate systems, they diverge. A single consistency model eliminates the daily reconciliation run that checks whether they agree.
Cleaner architecture for T+1 and beyond
Compressed settlement cycles increase the operational and reporting pressure on every exception. An architecture where exception state, audit history, and the operational entity lifecycle are the same thing scales better under that pressure than one built from multiple coordinated systems.
If your settlement architecture depends on ETL to answer what a regulator or auditor will ask, we'd like to talk.