What causes MT300 confirmation breaks in FX?

The four most common causes of MT300 confirmation breaks are: rate rounding differences (one counterparty rounds at 4 decimal places, the other at 6); value date mismatches from holiday calendar disagreements on T+2 settlement; notional differences when one side captures the trade in USD and the other in EUR equivalent; and SSI mismatches where the settlement instructions in the confirmation differ from what was agreed. In most confirmation matching programs, SSI data errors account for the majority of breaks — typically around 70%.

banking

MT300 Is the Most Important Confirmation Message in FX. Here Is What Breaks It.

Q: What is an SSI in FX settlement?

SSI stands for Standing Settlement Instruction. It is the pre-agreed set of payment routing details — correspondent bank, account number, BIC codes — that defines how funds should be delivered for a specific counterparty in a specific currency. SSIs are maintained in a centralised database and referenced automatically during trade confirmation and settlement. When SSI data is incorrect, outdated, or mismatched between counterparties, the MT300 confirmation breaks even if the trade economics are perfectly correct.

Q: How do you reduce MT300 confirmation break rates?

The most effective intervention is connecting the SSI database directly into the confirmation workflow — validating SSI data before every outgoing MT300 and cross-referencing it against incoming MT300s before acceptance. Since SSI errors account for approximately 70% of confirmation breaks in most FX operations, this single change produces a dramatic improvement in match rates. At Citi, this approach reduced the unmatched rate from 3% to 0.4% of daily volume within 90 days.

24 March 2026 · 7 min read · ... views

I managed FX confirmation and settlement at Citi across spot, forward, and swap books covering more than $3 trillion in annual settlement value. This post reached 4,000 impressions on LinkedIn. I have expanded it here with the full breakdown of what causes MT300 breaks and exactly what fixed them.

The MT300 is the SWIFT Foreign Exchange Confirmation message. Sent counterparty to counterparty within 30 minutes of trade execution. It confirms the economic and settlement terms of the transaction — currencies, amounts, exchange rate, value date, settlement instructions.

When it matches on both sides, the trade proceeds to settlement cleanly. When it does not match, you have two banks, one trade, and two different versions of reality. And at $3 trillion in annual settlement volume, a 3% unmatched rate is not an operational inconvenience. It is catastrophic.

Confirmation is not an administrative process. It is your last line of defence before settlement fails.

What the MT300 actually contains

The SWIFT MT300 Foreign Exchange Confirmation carries the complete record of an FX transaction between two counterparties. For a spot trade this means the traded currencies, the notional amounts in each currency, the agreed exchange rate, the value date, and the settlement instructions — specifically the SSIs, the Standing Settlement Instructions, that define exactly how each leg of the payment should be routed.

For forward and swap transactions the message structure extends to cover multiple legs, forward points, near and far leg details, and the settlement instructions for each. An FX swap generates two MT300 messages — one for each leg — and both must match independently.

The 30-minute confirmation window is a market standard, not a regulatory requirement in most jurisdictions. In practice, the faster the confirmation is sent and matched, the smaller the window in which a discrepancy can compound. Breaks discovered at T+1 are manageable. Breaks discovered at settlement time are expensive.

The four causes of MT300 breaks

In the confirmation matching program I directed at Citi, breaks fell consistently into four categories. Understanding which category a break belongs to determines how it should be resolved — and more importantly, how it should be prevented.

Rate rounding

FX rates are quoted and captured to varying decimal precision across different trading systems and counterparties. One bank's system rounds exchange rates at four decimal places. Another rounds at six. On a large notional, this difference produces a calculated amount that differs by a fraction of a unit — enough to fail an automated matching rule even though both sides are economically correct.

Rate rounding breaks are the most straightforward category to resolve — a tolerance band in the matching engine handles them cleanly. But they must be managed deliberately. A matching tolerance that is set too wide will accept genuine economic discrepancies. Too narrow and it generates false breaks on every large-notional trade.

Value date mismatch

FX spot trades settle on T+2 — two business days after the trade date. But "business day" is not universal. It depends on the holiday calendars of both the trading currency pair and the settlement location. When counterparties are using different holiday calendars — particularly for less common currency pairs or when one counterparty has a more comprehensive calendar than the other — the calculated T+2 date differs.

Value date breaks are operationally significant because they cannot be resolved by a tolerance. Either both sides agree on the value date or the trade must be amended. In cross-currency transactions involving jurisdictions with different public holiday schedules, this requires a maintained, current, and mutually agreed holiday calendar dataset. Stale or incomplete calendar data is a direct source of value date breaks.

Notional difference

In an EUR/USD trade, the notional can be expressed in either currency. One counterparty captures the trade as buying $10 million USD at 1.0850. The other captures it as selling EUR 9,216,589.86. The economics are identical. The notionals in each currency are derivations of each other using the agreed rate. But if the rate used to calculate the currency equivalent differs by even a fraction — due to rounding, system timing, or intraday rate updates — the calculated notionals diverge.

Notional differences are closely related to rate rounding breaks and often occur together. The fix is the same — tolerance management in the matching engine — but the root cause must be traced to determine whether it is a rounding issue or a genuine economic discrepancy.

SSI mismatch

This is the most important category, and the one most often underestimated.

The SSI — Standing Settlement Instruction — defines how funds are routed for a specific counterparty in a specific currency. It specifies the correspondent bank, the account at the correspondent, the BIC code, and any additional routing details required for the payment to reach its destination. SSIs are maintained in a centralised database and referenced automatically when generating settlement instructions and confirmation messages.

When the SSI referenced in your outgoing MT300 does not match the SSI your counterparty has on record for you — or when the SSI referenced in an incoming MT300 does not match what is in your own SSI database — the confirmation breaks. The trade economics are correct. The settlement instruction is wrong.

At Citi, when I directed an investigation into the root causes of our 3% unmatched rate, SSI data accounted for 70% of breaks. Not rate rounding. Not value date disagreements. Not notional differences. Settlement instructions.

What we did — connecting SSI directly into the confirmation workflow

The standard approach to SSI management at most banks at the time was maintenance-driven: SSIs were updated when they changed, counterparties notified, databases refreshed periodically. The confirmation workflow consumed whatever SSI was current at the time of matching.

The problem with this approach is that SSI breaks are discovered at confirmation matching time — which is already downstream of where they should be caught. By the time a break surfaces in the matching queue, a message has already been sent with incorrect settlement instructions, and a repair message must be sent to correct it.

The change I directed was to make SSI validation a pre-send gate for every outgoing MT300, and a cross-reference check for every incoming MT300 before acceptance.

Specifically:

Outgoing MT300 — SSI validated before send. Before every confirmation message was generated and sent, the system performed a real-time lookup against the SSI database to verify that the settlement instructions being included were current, complete, and matched the counterparty's known SSI for that currency. If the SSI lookup failed or returned a mismatch, the message was held and flagged for manual review before sending.

Incoming MT300 — SSI cross-referenced before acceptance. Every incoming confirmation was validated against our own SSI database before being accepted into the matching workflow. If the settlement instructions in the incoming message differed from what we had on record for that counterparty in that currency, the message was flagged before matching — not after.

This shifted the point of SSI break detection from the matching queue — where the break had already occurred — to the pre-send and pre-acceptance gates — where it could be intercepted before any message had been sent with incorrect instructions.

Within 90 days, the unmatched rate dropped from 3% to 0.4% of daily volume.

Why confirmation is not an administrative process

The framing I want to challenge is the one that treats FX confirmation as a back-office administrative function — a process that runs after the trade is done and surfaces breaks that the operations team then resolves.

Confirmation is an early warning system. An MT300 break is not a paperwork problem. It is evidence that two counterparties have different records of the same transaction. Until that break is resolved, neither party can be certain that settlement will occur as expected. At scale — and $3 trillion per year is scale — unresolved confirmation breaks accumulate into settlement risk exposure that can become material very quickly.

The earlier in the workflow a break is detected, the lower the cost of resolution and the lower the risk exposure while it remains open. A break caught at the SSI validation gate — before the MT300 is sent — costs a few minutes of operations time. A break caught at settlement time, when the value date has already passed in one time zone and the corresponding payment has not arrived, costs significantly more in time, cost, and counterparty relationship.

Designing the confirmation workflow to detect breaks as early as possible — and to prevent the most common category of break from occurring at all through SSI validation at source — is the engineering contribution to a problem that most organisations treat as a purely operational one.

At Citi, the 0.4% residual unmatched rate after the SSI integration represented the irreducible minimum of genuine economic discrepancies, genuine holiday calendar conflicts, and edge cases requiring human judgment. Everything above that was data quality — and data quality is an engineering problem.

Frequently asked questions

What is an MT300 SWIFT message?

The SWIFT MT300 is the Foreign Exchange Confirmation message — sent counterparty to counterparty within 30 minutes of trade execution. It confirms currencies, amounts, exchange rate, value date, and settlement instructions for spot, forward, and swap transactions. When both sides match, the trade proceeds to settlement. When they do not, confirmation breaks and settlement is at risk.

What causes MT300 confirmation breaks?

The four main causes are rate rounding differences between systems, value date mismatches from different holiday calendars, notional differences from currency equivalent calculations, and SSI mismatches where settlement instructions differ between counterparties. SSI errors typically account for around 70% of breaks — the trade is correct, the settlement instruction is wrong.

What is an SSI in FX settlement?

Standing Settlement Instruction — the pre-agreed payment routing details defining how funds are delivered for a specific counterparty in a specific currency. When SSI data is incorrect, outdated, or mismatched between counterparties, the MT300 breaks even when the trade economics are perfectly correct. SSI database quality is the single most important factor in confirmation match rates.

How do you reduce MT300 confirmation break rates?

Connect the SSI database directly into the confirmation workflow — validate SSI before every outgoing MT300 and cross-reference before accepting every incoming MT300. Since SSI errors account for ~70% of breaks, this single change produces the largest improvement. At Citi this approach reduced the unmatched rate from 3% to 0.4% of daily volume within 90 days.

Join the conversation

Loading comments...