Rethinking batches: an agile way to process trades within the T+1 timeframe
By James Maxfield, Head of Product and Solutions
In our last T+1 article we looked at traditional operating model design and why this will struggle with shorter settlement cycles. We also began to explore ways you can adapt your processes to discover exceptions faster, focussing on T+0 reconciliation. In this part, we’ll look at batch processing. What role does it play in the settlement cycle, why won’t this work for T+1 and what can firms do instead?
What needs to happen on settlement day?
Settlement date processing is typically driven by ensuring the mechanics are in place to support the delivery of securities and cash to meet settlement obligations. Inventory may be moved or recalled back in (it may have been lent or posted as collateral), treasury desks need to ensure funding is in place and last minute exceptions are focussed on. These could be some sub-accounts that are still pending set-up, SSI’s that need to be matched on a trade, or perhaps a counterparty still has missing instructions that are required by their custodian to ensure settlement occurs.
Many of these settlement date activities are driven at a position or aggregate level – positions or cash are viewed at a position level or on a net currency basis, to optimise the amount of movements involved and minimise excesses or deficits. This optimisation is important for any organisation, as credit line usage or excess liquidity are key focus areas for any CFO or treasury department.
None of this is possible if you are still affirming or matching your trades. Getting that out of the way requires you to manage and resolve your exceptions in a timely manner. Yet firms using a traditional operating model design often don’t discover breaks or exceptions until the morning of T+1.
All the exception discovery, investigation and resolution needs to be well underway by then as we think about how the move to T+1 reduces the time window for exception management.
So why does it take this long to discover the exceptions? In this article we’ll focus on one of the biggest reasons: batch processing.
Post-trade is built on batches
Many firms will reconcile all the day’s trades in one go at the end of the day. This made sense historically, as many organisations’ systems (and their service providers) were only able to generate data as part of an overnight batch process. The nature of these systems meant that they weren’t able to create or generate the extracts needed until processing day had finished. The start of day process on T+1 therefore commenced with looking at reconciliations or system driven exceptions to determine how exceptions were resolved.
The typical daily routine of a post trade organisation in a large financial institution therefore looks something like this:
- Morning: start the day with all exceptions from the previous day already flagged alongside exceptions that have carried over from prior days that have not been resolved. Work until midday sorting the exceptions by risk level – low, medium, or high. For example, exceptions between a front office platform and middle office platform where allocations are made.
- Afternoon: allocate exceptions to the appropriate teams to resolve based upon the root cause. For instance, the front office may need to rebook some trades. This could be, for example, because an exchange reconciliation has highlighted a mis-booking between a client order and the executions made on an exchange to fill them.
- End of day: check to make sure that all the morning’s exceptions have been addressed and fixed. For example, are exchange trades reconciled and the netted shapes matched to ensure there are enough securities to deliver settlement obligations.
Teams will run out of time if they overlay this approach to settlement processing on a T+1 time frame, as that leaves no time for the firm to carry out all the other activities required to settle trades. In addition, exceptions from prior days will also be backed up, as the loss of what is effectively one day from the settlement window compounds the exceptions management impact.
End of day reconciliation is too late in a T+1 timeframe
Moving to T+1 disrupts the entire workflow described above across all levels of the organisation. It’s no longer possible for tens, hundreds, or even thousands of operations workers to rely on this regular, mechanical sequence to process exceptions.
Instead, teams need to have a view of today’s exceptions, not yesterday’s. T+0 reconciliation needs to be happening throughout the day to discover exceptions as soon as possible. Teams need to work on these fluidly during the day as they arise, reacting quickly to issues.
For example, they’ll need a real time understanding of whether someone tasked with resolving an exception has taken the necessary action, such as the front office rebooking any trades they were asked to. Teams can’t afford to wait until the end of the day to find out either way: by then it’s already too late and the settlement will fail.
Yet none of the systems or processes under a traditional operating model design are set up to allow this.
Intra-day is the way
Shorter settlement lifecycles will impact the operating models, business structures, governance and control and oversight of people as established by a batch processing way of working.
It may seem that the alternative to batch processing is ‘real-time’ processing, but we prefer to think of it in terms of micro batches. While there is more to it than simply running smaller batches – because lots has to change to make this possible – it’s an easier concept to understand.
In fact, what we’re seeing from our customers in the post-trade space is demand for exactly this – micro batching – and not for real-time processing.
What does micro-batching look like?
Micro-batching involves running multiple intra-day reconciliations, which could be triggered when a certain volume threshold is hit, or at set times. This allows you to create exceptions in smaller batches, which can then be categorised, allocated and resolved as the day goes on.
Of course, for this to work you’ll need far greater levels of automation and transparency over your exceptions than those offered by legacy technology.
You need a system that can reconcile trades fast – certainly faster than overnight! – and is able to pinpoint the cause of breaks so that teams don’t have to spend time investigating root causes.
It needs to be powered by a best-in-class matching engine to remove the noise of false breaks and ensure teams can spend their time resolving genuine issues.
Automated workflow is essential – reconciliations should trigger, breaks should be categorised and allocated to the correct teams for resolution, without the need for human intervention.
The technology enabling micro-batch processing
Technology such as the cloud and machine learning will help empower firms to make the shift away from batch processing to micro batching as described above.
There are other pieces that you need to solve for as well to unlock this kind of approach. Our customers are currently focussing on submission orchestration. Under a micro-batches model you’re getting data from multiple feeds and sources throughout the day.
Data preparation plays a role here. You need a platform that can handle these small, frequent submissions in different formats, easily aggregate and transform the data, and automatically feed snapshots of it into your reconciliation platform when certain criteria are met.
But there’s a step beyond that – ensuring the quality of the data coming in before you even think about reconciling the files.
That means a complete overhaul of the traditional operating model. It involves moving away from an exceptions management focus and adopting a data-driven approach. We’ll look at exactly what that means and why it’s so powerful in the next article.
In this article we’ve explored the way most capital markets firms reconcile trades to create exceptions overnight, either using legacy systems or offshore teams (or, usually, both). We’ve seen how the move to T+1 will disrupt the systems and processes designed to support this batch processing way of working.
Instead, firms will need to think about shifting to a system of micro batches, giving them intraday visibility over their exceptions. This is a move towards a more agile way of managing data and addressing issues that could otherwise cause settlement failures.
Next time we’ll go a step further and discover how to become a data-driven organisation that proactively manages data quality.