Most corporate treasury teams know whether a payment settled, but they find out in the wrong order. The payment instruction goes out in the morning. Confirmation arrives in the afternoon batch, or via a manual investigation, or not at all until the beneficiary queries non-receipt. The reconciliation step happens after close. That timing sequence creates an intraday risk window that most treasury functions have simply accepted as normal, because the tools historically available did not make real-time confirmation practical.
The Risk Window Between Instruction and Confirmation
Consider a USD-EUR payment sent at 09:30 New York time to fund a EUR payable due same day. The instruction is transmitted via SWIFT. The expected settlement time, assuming the correspondent hits the TARGET2 cycle, is 15:00 CET. The treasury team learns whether the payment actually settled in the 15:00 cycle when the MT900 debit confirmation and the beneficiary bank's MT910 credit confirmation arrive, typically in the late afternoon batch.
In the interval between instruction and confirmation, the treasury's ledger position is unresolved. If the CFO asks at 14:00 whether the EUR payable has settled, the honest answer is "the instruction went out, no confirmation yet." If the payment failed for any reason, including a correspondent routing error, a cutoff miss, or a compliance hold, the treasury team will not know until hours later.
That window, roughly six to eight hours on a typical cross-timezone corridor, is not just an inconvenience. For treasury teams managing daily funding positions, it affects intraday liquidity decisions. If the team is not certain a EUR disbursement settled, they may hold an additional EUR buffer "in case," which is capital tied up for insurance against an uncertainty that should not exist.
SWIFT gpi and What It Actually Delivers
SWIFT gpi (Global Payments Innovation) was designed specifically to address confirmation latency. Payments carrying a gpi UETR (Unique End-to-End Transaction Reference) update a tracker record as each bank in the chain processes the instruction. The tracker shows: accepted, processed at each intermediary, confirmed credited to beneficiary account, with timestamps.
In practice, gpi tracking provides confirmation within minutes for corridors where all correspondent banks in the chain are active gpi participants. That covers the majority of high-value USD-EUR, USD-GBP, and USD-CAD flows today. The remaining exposure is in corridors where one or more legs involve a non-gpi participant or where the last-mile credit is into a local system outside SWIFT visibility.
gpi also carries a g4C (Confirm) obligation: the ultimate beneficiary bank must confirm credit within 24 hours. In well-adopted corridors, this happens in minutes, not 24 hours. But the 24-hour SLA is the contractual floor, not the operational norm, and a treasury team managing same-day EUR payables cannot plan around a 24-hour confirmation floor.
Where Batch Reconciliation Falls Short
The standard approach is end-of-day batch reconciliation: pull the MT940 account statement from the correspondent, match debits against payment instructions, mark settled or unmatched, investigate unmatched items. This works well enough when the payment volume is low and the corridors are stable. It breaks down under four conditions.
- High-volume days when unmatched items require manual investigation and the team does not have capacity to clear them before close.
- Month-end or quarter-end closes when every unresolved item affects financial statements directly.
- Cross-timezone corridors where the confirmation arrives in the next business day's batch because the settlement window closed after the team's working day.
- Corridors with frequent intermediary charges (SHA instructions with multi-hop paths) where the credited amount does not match the instruction amount, generating automatic reconciliation breaks.
In each of these cases, the problem is not that reconciliation is impossible. The problem is that it is happening too late to inform the decisions that depended on it.
What Real-Time Confirmation Changes Operationally
We are not claiming that real-time settlement confirmation eliminates all treasury risk or that it is critical for every payment type. Routine, non-time-sensitive supplier payments in stable corridors do not require intraday confirmation to manage effectively. The value concentrates in three specific scenarios.
First, same-day funding obligations where a failed settlement must be identified and re-initiated before local cut-offs close. Second, FX settlements where the two legs of a cross-currency transaction must match to avoid principal risk. Third, intraday liquidity management where the treasury needs to know actual settled positions, not estimated positions, before making drawdown or investment decisions.
In each of these cases, a treasury team that learns of a failed or delayed settlement in real-time has options. A team that learns at end-of-day batch reconciliation has fewer, or none.
The Reconciliation Implication
Real-time settlement confirmation is only useful if it feeds the reconciliation ledger automatically, not as a notification that someone must manually process. The confirmation record, tied to the payment instruction reference and the ISO 20022 end-to-end ID, should update the ledger position immediately so the open item clears without manual intervention.
When we built Birch Hill's confirmation flow, this was the architectural constraint we cared most about: settlement confirmation triggers an automatic reconciliation event that either clears the outstanding item or raises a flagged break for review. The goal is that by the time the controller looks at the ledger before close, the settled items are already cleared and only genuine breaks remain visible.