Starting in the Wrong Place Is the Most Common Error
Most post-trade automation conversations begin with settlement instruction management or straight-through processing from the OMS. That is a reasonable destination. It is not a reasonable starting point. The problem with automating settlement instructions before you have reliable break detection is that you end up automating both the correct settlements and the broken ones. The fail rate does not go down. It just moves downstream and shows up later, when it is harder to fix.
The sequence in which you automate post-trade operations matters more than the total scope of automation. The highest-leverage first step is almost always confirm ingestion and matching, not settlement instruction generation. Here is why, and how to stage the work.
Stage One: Get Reliable Ingest Before Anything Else
Confirm ingestion is where most ops desks lose time without realizing it. The workflow looks simple from the outside: counterparty sends a confirm, someone opens it, and the data goes into the spreadsheet. But at any real trading volume, the confirms arrive in three or four different formats: plain-text email from one broker-dealer, PDF attachment from another, a CSV drop from a third, and a SWIFT MT515 from a fourth. Each format needs to be read correctly before any matching logic can run.
Automating ingest does not require an IT project. For email-based confirms in plain-text body or PDF attachment, a parser that extracts ISIN, quantity, price, settlement date, and counterparty identifier handles the majority of formats if it is built to tolerate minor format variation. The key discipline is logging every parse attempt and flagging the ones that returned a partial result. If the parser cannot find the settlement date field on a particular counterparty's PDF, that is a configuration gap that can be fixed in a day. Without logging, that gap stays invisible and contributes to unexplained breaks.
The metric to watch in stage one is parse success rate per counterparty. A parser that successfully extracts all required fields on 97% of confirms from a given counterparty is production-ready for that counterparty. One at 80% is producing 20% missing data that the desk is filling in manually without knowing it. Getting parse success rate above 95% across all counterparties is the first milestone, and it is achievable without touching settlement infrastructure at all.
Stage Two: Matching Before Alerting
Once ingest is reliable, matching logic can run against your internal open positions or trade blotter. The matching layer compares the parsed confirm fields against what your system expects: does the quantity match, does the price fall within tolerance, does the settlement date agree, does the identifier resolve to the same security.
The matching step is where most desks overengineer in a way that creates more work. A matching system that generates an alert for every field that is not an exact match will produce so many alerts that the desk starts ignoring them. Matching logic needs to be calibrated to the actual tolerance ranges that matter. A price tolerance of plus or minus 0.02% on equities eliminates virtually all rounding-induced false breaks while still catching the genuine ones. A settlement date tolerance of one business day with a calendar cross-check handles the majority of holiday calendar differences without suppressing real settlement disputes.
The output of stage two should be two queues, not one: a confirmed match queue that the desk reviews weekly rather than daily, and an unresolved breaks queue that gets worked before the settlement deadline. The confirmed match queue should contain the vast majority of daily volume. The breaks queue should contain only positions where a human decision is actually required. If the breaks queue is the same size as the confirmed match queue, the matching tolerances are wrong and the classification is not working.
Stage Three: Break Detection Before Settlement Instruction
Only after matching is working reliably does it make sense to add automated break detection. Break detection is distinct from matching. Matching compares two confirms to each other. Break detection compares your matched position to your settlement ledger and flags positions that are on track for a fail: breaks where the counterparty has not affirmed, positions where the settlement instruction has not gone out, securities that cannot be delivered because they are not in the correct depository account.
Break detection run at 9am gives an ops desk the full trading day to resolve fails before the 4pm deadline. Break detection run at 2pm gives two hours. The value of automating break detection is not just the detection itself but the early timing it enables. A manual process that scans for breaks at noon is doing detection four hours late simply because the work takes that long.
We have seen desks where break detection automation at stage three cut the fail rate by a substantial margin with no change to settlement instruction workflows at all. That result reflects what the original 4pm calls were really about: not that the desk lacked the right instructions, but that the breaks were not visible early enough to act on.
Stage Four: Settlement Instruction Automation Has Prerequisites
Automating settlement instruction generation is where the largest efficiency gains live, and also where the largest risks live if the upstream stages are not solid. A settlement instruction that goes out with a confirmed match against a validated open position has a very high probability of settling correctly. A settlement instruction that goes out against a partially-parsed confirm or an unresolved break does not.
The prerequisite for stage four is not a technology choice. It is a data quality level: parse success rate above 95%, matching tolerance calibrated to produce a low false-break rate, and break detection running before noon. When those three conditions hold, settlement instruction automation reduces the desk's manual workload without increasing the fail rate. When they do not hold, automation accelerates fails and makes them harder to trace.
Catena's approach is to let the desk start at stage one without an IT project, calibrate the matching tolerances against real confirm data, and only surface the settlement instruction workflow after the matching and break detection layers have been validated. That sequence is not the fastest way to implement automation. It is the way that produces a lower fail rate at the end of the process, which is the metric that actually matters for an ops desk.
What This Sequence Is Not Saying
This staging approach does not mean you have to wait for perfect ingest before starting any automation, or that you cannot run stage two and three in parallel once stage one is solid. It means the upstream stages constrain the reliability of the downstream ones. A desk that has good matching data can start break detection quickly. A desk that has poor parsing coverage will generate false breaks at every stage until the parsing is fixed. The constraint is real, and working around it creates more work than respecting it.
The desks that get the most out of post-trade automation are the ones that start with clear metrics: parse success rate, false-break rate, break detection timing. Those metrics tell you when each stage is ready to support the next one. Without them, the decision to move to the next stage is a guess, and the fail rate is the feedback that tells you the guess was wrong.
