Revolutionizing your post-trade and banking reconciliation process

Post-trade reconciliation is the process of matching a firm’s internal trade records against external sources after execution and before final settlement. Those sources could include counterparties, custodians, clearinghouses, prime brokers, or market infrastructure providers.

The purpose is simple yet critical - identify reconciliation breaks before they become settlement failures, reporting issues, or operational risk events.

Post-trade reconciliation usually spans several layers. Trade reconciliation checks transaction-level details such as price, quantity, counterparty, fees, currency, and settlement date. Position reconciliation verifies that the securities a firm believes it holds match the records maintained by custodians, depositories, or other external parties. Cash reconciliation confirms that the movement of money aligns with expected settlement activity, funding flows, fees, margin, and corporate actions.

None of this is new to operations teams. The difference now is that a delayed break has less time to be recovered before settlement.

Since May 2024, the US equity market has operated on a T+1 settlement cycle, reducing the standard settlement window from two business days to one. For post-trade reconciliation teams, that means less time to surface, investigate, escalate, and correct breaks before they become settlement issues. A break that might once have been identified overnight and resolved the next day now needs to be visible much sooner.

The mechanics of post-trade reconciliation are well understood. What is less often addressed is why so many reconciliation processes, even inside sophisticated institutions, are still structurally designed for a settlement cycle that no longer exists.

Why Most Reconciliation Processes Are Built for Yesterday

Most post-trade reconciliation processes were not designed for the market structure they now have to support.

They were built around longer settlement windows, lower product complexity, and operating models where an overnight batch could still function as a meaningful control. The margin for delayed exception visibility is much smaller under T+1. One fewer business day to identify, investigate, escalate, and resolve breaks completely changes the risk profile. A process that only tells the team what went wrong the next morning leaves operations working from information that has already lost time-sensitive value.

The same issue appears when firms launch new products or add complexity to existing ones. The front office moves quickly, as it should. But if the reconciliation layer cannot absorb that change from day one, operations teams are left reaching for tactical spreadsheets to keep pace. That may solve the immediate problem, but it also creates technical debt. Temporary fixes become permanent controls once teams depend on them for daily exception management.

Regulatory expectations have moved in the same direction. Reconciliation now has to produce clear evidence of speed, ownership, consistency, and auditability. Exceptions should surface quickly, with visible ownership and consistent break tracking. The audit trail should show what happened, when it happened, who acted, and how the issue was resolved.

Many reconciliation processes still rely on workflows built for a different settlement cycle, product environment, and standard of control. The risk comes from the mismatch between the original design of the process and the market it now has to support.

Front-Office Innovation Requires Back-Office Agility

Firms naturally look to differentiate themselves by launching new products, entering new markets, and adding more sophisticated features to existing offerings. But every time the front office moves, the control environment has to move in lockstep.

Post-trade reconciliation teams are often the first to feel that pressure. Without tooling that can bring a new control live quickly, the fastest route is usually a spreadsheet. The temptation is understandable. Nobody wants the back office to be the reason a product launch slows down.

But this is how Excel hell begins: one tactical workaround becomes two, then ten, then an informal control framework held together by accumulated fixes. This is also why spreadsheet-based controls can become expensive to unwind.

Under T+1, launching a new product before the reconciliation layer is ready creates more immediate settlement consequences. The first serious break may already be inside a compressed resolution window before the control has caught up.

A pattern that manifests across operations teams at this scale is that tools which perform well in simple proof-of-concept scenarios struggle when they meet complex products, messy data, and real exception workflows.

Always evaluate vendors against the hardest problems your reconciliation teams face.

The Problem With Solving the Wrong Problem

One of the most persistent cost drivers in reconciliation operations is process complexity that survives long after the original constraint has disappeared.

Many reconciliation processes become more complex for practical reasons. A legacy system cannot support the required integration. A downstream platform needs data in a different format. A team adds a manual check because the system cannot provide the required visibility.

The process keeps moving, but the control becomes hard to operate, harder to audit, and easier to misread during exception management.

A common example is a team that exports reconciliation results into a spreadsheet, reformats them, and feeds them into another system. The manual export step adds avoidable operational risk when results could flow directly into the downstream systems that need them.

A like-for-like replacement of a legacy post-trade reconciliation process can preserve the same inefficiencies in a cleaner interface. The better starting point is to examine which steps still support the control, which ones were added to work around old tooling constraints, and which ones can be removed entirely.

The biggest reductions in cost and risk often come from re-imagining - not replicating - the process.

N-Way Reconciliation: Why One-to-One Matching Is No Longer Enough

Traditional reconciliation compares two datasets - internal records against one external source. N-way matching extends that control across multiple systems simultaneously, with order management system, execution management system, prime broker, custodian, and clearinghouse records checked in parallel rather than sequentially.

Breaks can surface at different points across the post-trade chain. A trade that matches one source can still carry a price, quantity, timing, or settlement discrepancy when checked against OMS, EMS, prime broker, custodian, and clearinghouse records together. N-way reconciliation gives operations teams a wider control surface and a clearer view of where the inconsistency entered the process.

It also reduces operational complexity. Instead of maintaining separate reconciliations for each relationship between systems, firms can consolidate matching logic into a single process that shows where the inconsistency sits and which team needs to act.

The £1.3 billion rogue trading example shows why this capability is commercially significant. After the incident, a major global bank implemented N-way matching across dozens of systems. Trades could be checked within 30 minutes, allowing discrepancies to be escalated and resolved before they became larger control failures.

The strength of a post-trade reconciliation control comes from how early it exposes the exception and how quickly the right team can act.

T+1 and the Pressure on Real-Time Controls

T+1 gives reconciliation teams less room to absorb late exceptions before they become settlement risk. Gresham has previously examined the pressure T+1 settlement places on data, breaks, controls, and operational processes.

In a T+2 environment, a break identified late in the day still had room to be investigated, escalated, and resolved before settlement. With T+1, the same break might surface inside a far tighter window, with less time for manual investigation and fewer chances to recover from upstream delay.

Post-trade reconciliation processes built around overnight batch runs are now structurally misaligned with the settlement cycle. Next-morning exception reporting leaves operations teams working with stale control information inside a compressed settlement window.

The firms that adapted most cleanly to T+1 already had reconciliation infrastructure built for intraday exception visibility, clear ownership, and faster escalation. They were able to treat reconciliation as an active control because exceptions showed up while there was still time to act.

While T+0 may not be an immediate regulatory requirement, the direction of travel is clear. Firms still rearchitecting for T+1 need to avoid building a control model that is already one settlement cycle behind.

What Good Looks Like in Modern Reconciliation Infrastructure

A modern post-trade reconciliation function is built around live exception visibility. The control starts to prove its value when a break is surfaced, assigned, investigated, and acted on while there is still time to resolve it.

Integration has to be designed into the process from the beginning. Reconciliation results should flow directly into downstream risk, reporting, regulatory, and operational systems without users having to export, reformat, and rekey data between platforms.

The infrastructure also has to be configurable enough to absorb new products, data sources, and control requirements without a bespoke build each time. That is what prevents every product launch from creating another spreadsheet workaround.

Strong reconciliation depends on strong data management, including clear data lineage across upstream sources, transformations, and downstream systems. Matching logic can only be as reliable as the data feeding it. Inconsistent, incomplete, or poorly governed source data weakens the reconciliation workflow before matching even begins.

Firms building for T+1 today need infrastructure that could accommodate T+0 tomorrow. Institutions with reconciliation logic decoupled from legacy data architecture will be better placed to adapt if settlement cycles compress further.