Matt Swinburne-Johnson

It would be easy to make spreadsheets the villain of T+1, but that would also be unfair.

Spreadsheets are popular for very good reasons. They are flexible, familiar and incredibly useful. When a core system cannot perform a calculation or a new process needs to be running by Friday, the spreadsheet has an admirable habit of coming to the rescue. 

The problem starts when the rescue becomes permanent and ad-hoc at the same time.

Across financial services, spreadsheets can quietly evolve from useful tools into pieces of operational infrastructure without anybody formally deciding that should happen. A temporary calculation becomes part of the daily process, a macro gets passed from one employee to another, more tabs arrive and more logic accumulates and at some point nobody is quite sure how it all works.

Eventually, a business-critical decision can depend on a file that was never designed to become a business-critical application.

T+1 is unlikely to be kind to that operating model.

Time compression exposes fragility

Under a longer settlement cycle, spreadsheet-driven activity has room to breathe. Somebody exports a file, somebody performs a lookup, somebody checks the output, a discrepancy is investigated and a corrected version gets circulated.

None of those activities necessarily takes very long individually, but each one introduces latency and variability.

The UK move to T+1 will reduce available processing time by around 80%, according to the FCA. The regulator has specifically urged firms to identify manual processes and blockages that could prevent transactions settling within one business day.

That puts spreadsheet-based processes firmly under the spotlight.

The most dangerous errors are often quiet

A broken core system tends to announce itself. A spreadsheet error can be much more discreet.

A formula gets overwritten, a range does not include the latest row, a macro behaves unexpectedly or a lookup references an old file. Two people may work from different versions, or an assumption may change while the formula implementing it does not.

Nothing necessarily crashes. The spreadsheet still produces an answer.

That is precisely what makes uncontrolled spreadsheet logic dangerous in a time-critical process. The problem may only become visible several steps later, when the information fails a reconciliation or creates a settlement exception.

By then, under T+1, the clock is already working against you.

There is a visibility problem too

When operational logic sits outside controlled platforms, senior teams can struggle to get a complete picture of how their processes actually work.

It may not be immediately clear which spreadsheet drives a calculation, who owns it, who can change it, when it was last updated or whether the change was tested. Reproducing a calculation from several months earlier may also be difficult, particularly where knowledge of the process sits with a small number of individuals.

Those are governance questions as much as technology questions.

For firms within the FCA's operational resilience framework, understanding the people, processes, technology, information and third parties supporting important business services is already an established expectation. An important piece of business logic should therefore be treated like an important piece of business logic, regardless of whether it happens to live in Excel.

The people problem behind the spreadsheet

Often, the real intellectual property does not live in the spreadsheet at all. It lives with the person who built it.

They know why one formula behaves differently for a particular transaction. They understand which output looks wrong even when the calculation says it is correct. They know the workaround needed at month end.

That knowledge is hugely valuable, but it can also represent a single point of failure. Absence, employee turnover or a simple mistake can expose how dependent a process has become on individual expertise.

T+1 makes that dependency harder to accommodate because there is less time for somebody else to understand what has happened and put it right.

Is your spreadsheet a tool or part of your infrastructure?

A useful way to find out is to ask:

    • Does the spreadsheet determine whether a transaction can proceed?
    • Does it contain business rules, calculations or validations not held elsewhere?
    • Would settlement activity be disrupted if the file were unavailable?
    • Does someone manually copy data into or out of it?
    • Are outputs manually uploaded into another platform?
    • Can multiple versions exist at the same time?
    • Can users change important logic without formal testing or approval?
    • Would you struggle to explain exactly how an historic output was calculated?
    • Does successful operation depend heavily on one or two people?
    • Would higher volumes require additional people to keep the process running?

If the answer is yes to several of those questions, the issue is no longer whether your organisation “uses spreadsheets”. Almost every organisation does.

The real question is whether a spreadsheet has quietly become a critical application without the controls you would expect a critical application to have.

Industrialising the logic, not replacing everything

Solving spreadsheet risk does not necessarily mean rebuilding every process from scratch. Often, the valuable part is the logic itself.

The business already understands what needs to happen and the spreadsheet may even have proven the rule over many years. What needs to change is the way that rule is controlled and executed.

A rules engine such as Heywood Idiom can take calculations, validations and decision logic that currently sit outside core systems and turn them into controlled, executable rules. Those rules can be made visible, tested and governed centrally, while Idiom works alongside the organisation's existing technology.

That distinction matters because the answer to T+1 does not have to be another enormous replacement programme. For many firms, a more pragmatic approach will be to identify the highest-risk manual processes and progressively remove the spreadsheet, email and human interpretation sitting between otherwise capable systems.

Spreadsheets will remain one of the most useful tools in business, but useful and appropriate are not the same thing. A spreadsheet used by an analyst to explore an idea is very different from one performing a critical calculation in a time-sensitive settlement process.

T+1 makes that distinction increasingly important.

Take a closer look at your manual processes

If spreadsheets, macros or other off-platform processes form part of your settlement operating model, now is the time to understand where they could create risk under T+1.

Heywood can help you identify the business logic sitting outside your core systems and explore how Idiom could automate and control those rules without requiring a wholesale technology replacement.

Talk to Heywood about reducing spreadsheet and manual process risk ahead of T+1.