Marking a trade settled says your operation stopped waiting. Settlement itself is the extinguishing of several separate obligations, on a calendar set by banks, through a payment that becomes irreversible at a moment your system never observes, against instructions that can change without the trade changing.
Summary
A trade is marked settled when the last thing your operation was waiting for has arrived. That is a statement about your records, and settlement is not a fact about your records. It is the extinguishing of several separate obligations, on a timetable set largely by other people, through a payment that becomes irreversible at a moment your system does not observe, against instructions that are a different object from the trade and can change without the trade changing. Marking a trade settled is a claim, and it is made by the party with the least ability to verify it.
This article sets out what settlement actually consists of: why "settled" is a per-obligation state that gets reported as a per-trade state, why the calendar that governs the moment belongs to banks rather than to your desk, why a payment that has been sent is not a payment that is final, why the instruction the money follows has its own life independent of the trade, and why closing a trade removes exactly the context you need if it is ever reopened. It is written for the people who carry it — settlement and treasury operations who execute it, middle office who report a book as closed, and the traders and controllers who find out later that a closed trade was not finished.
If you want the mechanism, start with "Settled" is not one state, and it is reported as though it were. If you already run settlements and want the part that costs the most and is discussed the least, start with Closing the trade removes what would defend it.
"Settled" is not one state, and it is reported as though it were
A trade does not have a settlement status. It has several obligations, each extinguished by a different party at a different time, and the single flag on the trade record is a summary of them that nobody computed.
Consider what has to end before a physical commodity trade is genuinely over. The delivery obligation has to be discharged, and evidenced. The invoice has to be paid, and the payment has to arrive. Where quantity or quality differed from what was assumed, an adjustment has to be agreed and then itself settled. If the trade was hedged, the hedge has to be closed and its own cash flows exchanged, on its own schedule. Margin that was posted has to come back. Any claim arising from the voyage has to be resolved or formally dropped. Documents held as security have to be released.
Each of those is a separate obligation with a separate counterparty action behind it. A trade is finished when all of them are finished, and there is usually no single place in a trading business that knows whether they all are. The delivery is known to operations. The payment is known to treasury. The hedge is known to the trading system. The margin is known to whoever reconciles the broker statement. The claim is known to whoever is arguing about it.
What exists instead is a flag, set by the function that was waiting longest, meaning "we are no longer waiting". That is a useful operational signal and it is not the same statement. The gap between "nothing is outstanding here" and "nothing is outstanding anywhere" is where trades go quiet while still owing something — and quiet is the state in which nobody looks at them.
Somebody else's calendar decides when this happens
Settlement is the one step in the trade lifecycle whose timing is set by institutions you are not trading with, on a calendar you do not control and often do not hold.
A payment instructed today does not move today because you instructed it today. It moves according to the cut-off of the sending bank, the value-date convention of the instrument, the business days of the currency's home jurisdiction, and — where the payment crosses banking systems — the timetable of every correspondent in the chain. None of those are your counterparty's decisions either. Both sides can behave perfectly and the money can still arrive on a different day than either expected.
Three things follow that are ordinary and are routinely modelled wrong.
A cut-off is a deadline, not a queue. An instruction released a few minutes late is not a slightly slower payment; it is a payment on the following business day, and if that day is a holiday somewhere in the chain, it is later still. The cost of missing a cut-off is discontinuous, which is why it surprises people who think of it as a delay.
The relevant holidays are not your holidays. The days that matter are the ones observed by the currency's home market and by each institution the payment passes through. An operation working normally can find a payment sitting still because a market it has no relationship with is closed.
And the chain is invisible from your end. You instruct one bank. What happens after that is a sequence you did not choose and cannot see, and "it left us" is a true statement that tells you almost nothing about when it will land.
The practical consequence is that a settlement date in a trading system is usually an intention. It is what the trade said should happen. Whether it happened is a different fact, arriving later, from a different source.
Sent is not final, and the gap belongs to you
A payment passes through several states, and only the last one is irreversible. The state a trading system records is the first one, because that is the only one it originates.
There is a moment when a payment is instructed, a moment when the sending institution acts on it, a moment when the funds are available to the receiver, and a moment when the transfer becomes irrevocable as a matter of the system it travelled through. These are four different moments, they can be spread over days, and the differences between them are not administrative detail.
Until finality, something can still go back — a recall, a rejection for a defective reference, a return because the receiving account did not accept it, a reversal because the sending institution was told to stop. That is not a failure scenario; it is how payment systems are designed to behave. But it has a direct consequence for exposure: you are still owed the money, and your book says you are not. The position was closed on the strength of an instruction rather than on the strength of an outcome.
The reverse case is quieter. A payment arrives, and nobody is certain which trade it belongs to, so it sits unapplied. The counterparty believes they have paid, and they have. Your records say the trade is unpaid, and it is. Neither statement is about the same event: "paid" happens at their end and "applied" happens at yours, and nothing in between is anybody's job. The money is in your account and the trade is outstanding at the same time — a condition that produces no alert anywhere, until somebody starts chasing it.
The distinction that matters is simple to state and rarely implemented: a settlement record should say which of the four states it is in, on what evidence, and from which source that evidence came. A single flag cannot carry that, whatever it is holding it in.
The payment runs on instructions, not on the trade
The money follows a settlement instruction — an account, a bank, a reference — which is a separate object from the trade, with its own history, its own owner and its own authority. A trade can be entirely correct and still pay the wrong place.
Settlement instructions are usually held once per counterparty and reused, which is the right design: re-keying an account for every trade would be worse. But it means the instruction is a piece of standing data that many trades depend on, and standing data changes. Counterparties reorganise, change banks, move entities, restructure their group. When they do, the change arrives — by message, by email, by a note in a phone call — and it arrives at whoever happens to receive it.
That produces a control question which is not really a settlements question at all: who is permitted to change where your money goes, and what has to be true before they can. The answer is a matter of process design rather than of care, for the same reason that applies everywhere else in this lifecycle — the person receiving a plausible change request under time pressure is not well placed to be the only check.
Two further properties are worth stating because they are easy to miss.
The instruction is not verified by the trade being right. The downstream checks a settlements function runs — does the invoice match the contract, does the amount match the calculation — validate the amount. None of them validate the destination. A payment can pass every reconciliation you perform and go somewhere it should not.
And an instruction that has changed is retroactively relevant. When a counterparty's details change, the question is not only what happens next; it is whether anything already instructed and not yet final is affected. That question is answerable only if you can see which payments are in flight, which brings this back to the previous section.
Closing the trade removes what would defend it
Settling a trade takes it out of the working set: the position closes, the hedge is gone, the file is archived and the people move on. If the trade is reopened, the context that would resolve it has been dismantled — and reopening is normal.
Trades come back. A quality claim surfaces after the cargo has been processed. A demurrage claim arrives from a party who took months to compile it. A counterparty's audit produces a query about a calculation from two years ago. A tax authority or an auditor asks how a figure was arrived at. None of these are unusual events, and every one of them arrives after the trade has been marked finished.
What has usually been lost by then is not the numbers. It is everything that explains them.
The reasoning is gone even where the record remains. The invoice is archived, but the reason a particular measurement was used, or a particular adjustment accepted, lived in a message thread or in the judgement of somebody who has since changed roles. The record shows what was done and not why it was reasonable.
The comparison has gone stale. The market data, the curve, the assessment that supported a valuation at the time can be hard to reproduce as they stood, which turns "show us your basis" into an archaeology exercise rather than a lookup.
And the incentive has inverted. While a trade is live, several people have a reason to keep its file straight. Once it is settled, nobody is measured on it. The file stops being maintained at precisely the moment its future value is highest, because its future value is entirely contingent — a closed trade is unlikely to be asked about at all, and when one is, it is asked about hard.
The useful reframing is this: the cost of settlement is not the effort of settling. It is the cost of the questions you cannot answer afterwards — and that cost is decided by what was captured on the way through, not by what anyone can reconstruct later.
Where this leaves the middle and the back office
Settlement is the end of the lifecycle, which means it inherits every ambiguity that was left open earlier and has to resolve all of them into a single irreversible act. That is a structurally unfair position, and it explains a pattern that otherwise looks like a back-office performance problem.
The information required to settle correctly is produced by other functions on their own schedules and in their own formats. The delivery evidence comes from operations. The adjustment comes from an inspector's certificate. The hedge cash flow comes from a broker statement. The payment confirmation comes from a bank, in a format the bank chose. The instruction comes from a counterparty by message. Settlement's job is to assemble all of that into one act, and to do it before a cut-off it does not set.
Two things follow, and both are about where effort is best spent.
The scarce thing is not diligence. Settlement teams check carefully; that is the whole culture of the function. What they cannot do is check what did not arrive in a usable form, or verify a destination that no process was designed to verify.
And the flag is doing too much work. A single settled/unsettled marker is asked to represent several obligations, four payment states and a set of open questions, all at once. Any status that cannot be wrong is not carrying information, and a flag set by the last function to stop waiting cannot be wrong — it faithfully reports that somebody stopped waiting.
What has to be extinguished before a trade is settled
| Obligation | Who ends it | What says it has ended |
|---|---|---|
| Delivery of the goods | Operations and the counterparty | Delivery or discharge documents |
| The invoiced amount | The paying party's bank chain | Funds received and applied to that trade |
| Quantity and quality adjustment | Both parties, against an inspection result | An agreed adjustment, then its own payment |
| Hedge cash flows | The exchange, broker or swap counterparty | Statement lines, on the hedge's own schedule |
| Margin or collateral posted | The party holding it | A return, which somebody has to ask for |
| Claims arising from the voyage | Whoever is arguing about them | An agreement, or a formal decision to drop it |
| Documents held as security | The holder | Release, which is a positive act rather than an expiry |
Read down the last column. Almost every line is evidenced by something produced outside your organisation, on somebody else's schedule, in a format you did not choose. That is the reason settlement status is hard to assert and easy to declare.
Four states a payment passes through
| Instructed | Sent | Received | Final | |
|---|---|---|---|---|
| What has happened | You have told your bank to pay | Your bank has acted | The funds are available to the receiver | The transfer can no longer be reversed |
| Who knows first | You | Your bank | The receiver | The payment system it travelled through |
| Where a trade record usually stops | This one, recorded as "settled" | Sometimes | Later, from a different source | Not normally observed at all |
| What can still go wrong | Everything below | Rejection, return, recall | Received but not applied to the trade | Nothing, which is the point |
| Whose exposure it is meanwhile | Yours | Yours | Yours, though nobody feels it | Nobody's |
The bottom row is the one to sit with. For three of the four states you are still exposed, and for two of them your own records have probably already said you are not.
Questions people ask about this
What does it actually mean when our system says a trade is settled?
Usually that the function which was waiting longest has stopped waiting. That is a real signal and it is narrower than the word suggests: it does not assert that the hedge cash flow was exchanged, that posted margin came back, that an adjustment was agreed and paid, or that the payment became irreversible rather than merely instructed. Whether your flag means more than "we stopped waiting" is worth establishing, because it is the number that gets reported upward as though it meant everything on that list.
We instructed the payment, so why is the exposure still ours?
Because instructing a payment is a message to your bank, not the arrival of money. Between instruction and finality the transfer can be rejected, returned or recalled, and until it is final you are still owed. This is not a defect in anyone's process — payment systems are built to allow those things. It matters because the instruction is the event your side originates, so it is the event your side naturally records; the later states have to arrive from elsewhere, and if nothing brings them in, the book reports a completed trade while the exposure is still live.
The counterparty says they paid and we say they have not. Who is wrong?
Often neither. "Paid" is an event at their end and "applied" is an event at yours, and a payment that arrives without enough information to identify which trade it belongs to sits unapplied while both statements remain true. The first thing to check is not the counterparty's claim but your own unapplied receipts — because the alternative is opening a collections conversation over money already sitting in your account, and that outcome is uncomfortable enough to be worth one query.
Why did the money arrive later than the settlement date on the trade?
The settlement date in a trading system is what the contract said should happen. When it happens is decided by bank cut-offs, the value-date convention, the business days of the currency's home market, and the timetable of any correspondent banks in between. An instruction released after a cut-off does not arrive slightly later; it arrives on the next business day of a calendar you may not hold. Both parties can behave correctly and still be surprised.
How can a payment be right on every check and still go to the wrong place?
Because the checks validate the amount and the destination is carried by something else. The account details come from a settlement instruction, which is standing data held per counterparty and reused across many trades. Matching the invoice to the contract confirms how much; it says nothing about where. The two questions have different owners and often different levels of scrutiny — which is worth knowing before deciding that reconciliation is a sufficient control.
A counterparty has sent us new bank details. What is the actual risk here?
That the change is acted on by whoever received it, under time pressure, as a routine administrative task. The useful control is not more vigilance from that person; it is a rule about who may change where money goes and what has to be independently true first. It is also worth asking a second question that gets forgotten: whether any payment already instructed and not yet final is affected by the change, which you can only answer if you can see what is in flight.
A closed trade from two years ago has been queried. Why is this so expensive?
Because settling a trade dismantles the context that would answer the query. The numbers are archived, but the reasoning behind a particular measurement or an accepted adjustment usually lived in a message thread or in somebody's judgement, the supporting market data can be hard to reproduce as it stood, and nobody has been maintaining the file because nobody is measured on closed trades. The cost was created when the trade was closed, and it is paid now.
What is the smallest change that would improve our settlement position?
Stop treating settled as one flag. Record, per trade, which obligations from the list above are actually extinguished and on what evidence, and record which of the four payment states each payment has reached and where that information came from. It is a modest change to what gets stored, it produces an immediate and usually uncomfortable picture of how many trades are reported finished while something is still open, and it does not require replacing anything.
Where this lands in a trading system
Nothing above is an argument for buying software. It is an argument about what a settlement record has to distinguish, and about where the evidence for each distinction comes from. Parts of it do map onto system capabilities and parts of it firmly do not.
The first conclusion is that settlement is a set of obligations belonging to one trade, and that they can only be tracked together if the trade and its downstream consequences live in one place. That is the job of a CTRM/ETRM system providing complete trading lifecycle management for commodity traders, integrating physical trade, financial hedging, risk control, and settlement in one platform; Time Dynamics' Fusion is one, and the capability that bears directly on this article is automated financial settlement and payment processing — used here in its own terms, which describe processing settlements, not deciding that one is complete.
The second conclusion is that the evidence which closes each obligation arrives from outside: bank confirmations, broker statements, inspection results, counterparty messages. Getting those into the same place as the trade is what X-Ray addresses — a non-invasive data processing and analysis platform designed specifically for enterprise clients, whose collection toolkit XDK performs non-invasive automated data collection from databases, Excel files, and web interfaces, and which is built to collect data without disrupting existing systems or workflows. That last property is the relevant one here, because a settlements team cannot pause during a month end and no bank is going to change its file format for you.
The third conclusion is that some settlement facts are worth being told about rather than looked up — a payment that has not progressed, an obligation still open on a trade reported as closed. X-Eagle provides real-time risk alerts and monitoring for trade finance field warnings. That is its own described scope, and it is worth being exact rather than generous about it: whether such a mechanism is pointed at a settlement field rather than at the trade finance fields it names is a configuration question rather than something a platform decides for you — though a warning on a field that has not changed when it should have is an ordinary shape, not an exotic one.
No system on this page moves money, and none of them makes a payment final — finality belongs to the payment system the transfer travelled through, and no record of yours can confer it. It will not tell you that a change of bank details is genuine; that is a control over people and authority, and a platform that claimed to settle it would be selling you a false sense of security in the one place you can least afford one. It does not agree anything with your counterparty, and their books remain theirs. It will not reconstruct the reasoning behind a decision made two years ago that nobody wrote down. What a system can settle is narrower and duller than the problem in this article: which obligations on a trade are actually extinguished, on what evidence, from which source, and whether the person asked about it next year can see that without finding the person who was there. That is a real part of the gap, it is not the whole of it, and knowing the difference is worth more than any feature list.
A note on the evidence in this article
There are no statistics here, and that is deliberate rather than an omission. The observations behind it — how settlement status is actually recorded, what is known at each stage of a payment, what survives the closing of a trade — come from material we are not in a position to publish as a citable figure. A number nobody could check would make this argument read as stronger and would make it worth less.
So the argument runs on mechanism, and it is written to be tested against your own operation rather than accepted. Three checks are proposed above and they are the intended use: take a sample of trades your system reports as settled and see how many still have an obligation open somewhere on the list, look at how many of your payment records distinguish instructed from final, and pick one closed trade from two years ago and try to answer why a particular adjustment was accepted. If your own operation answers those differently from what is written here, your operation is the better evidence.