What Is COB in T24?

If you work in a T24 environment long enough, you will hear someone say something like "COB failed" or "COB is running long" or "we need to wait for COB to finish." These statements get thrown around a lot, and they usually carry a certain weight — because when COB goes wrong, nothing else happens until it is sorted out. Also, someone senior is now standing behind you, and they have not said anything yet.

But what actually is COB? What does the system do during those hours when nobody is supposed to be logged in? And why does it sometimes take longer than expected, or fail in ways that are hard to explain?

This article answers those questions from the ground up. No prior COB knowledge required. Just a vague sense that something important happens at night and you are responsible for it.

What COB actually does

COB — Close of Business — is the daily batch processing cycle in Temenos Transact. It is the period when the system processes everything that needs to happen at the boundary between one business day and the next. Think of it as the system's nightly admin shift, except it does not complain about the hours and it never asks for overtime.

During COB, the system:

• Moves the system date forward to the next business day
• Processes all scheduled activities that are due on that date
• Runs end-of-day calculations — interest accruals, fee postings, limit updates
• Generates accounting entries for everything that happened during the day
• Produces reports, statements, and regulatory outputs
• Prepares the system for the next day's online activity

In short, COB is the engine that turns a day's worth of transactions into updated balances, posted entries, and a clean state for tomorrow. Without it, nothing moves forward. It is also the reason you have ever had to explain to a non-technical manager why the system is unavailable between 2am and 4am, and why that explanation was met with a look that suggested you had just made the whole thing up.

COB is not one thing

One of the most common misunderstandings is that COB is a single process that either succeeds or fails. In reality, COB is a sequence of many individual jobs, each with its own purpose, its own dependencies, and its own creative ways of failing.

A typical COB sequence includes:

• Pre-COB checks — verifying that the system is in a consistent state before processing begins. This is where COB tells you it is about to start, which is the last communication you will get from it for a while.
• Date rollover — advancing the system date and updating all date-dependent fields. If this fails, the rest of COB does not know what day it is, which is surprisingly common.
• Batch processing — running the scheduled jobs that process transactions, calculate interest, post fees, and update limits. This is the main event. It is also where most things go wrong.
• Post-COB processing — generating reports, statements, and regulatory files. The part that nobody notices until a regulator asks why a report was not produced.
• COB completion — final checks and handover back to online mode. The moment of truth where you find out whether you can go home or whether you are about to send an email that starts with "COB did not complete overnight."

Each of these stages can contain dozens or even hundreds of individual jobs, depending on the size and complexity of the installation. A job that fails early in the sequence can block everything that comes after it. This is why the first rule of COB support is: never assume the failure you are looking at is the real problem. It is probably just the first domino.

Why COB matters

COB matters because it is the point at which the system reconciles itself. Everything that happened during the online day — transactions, amendments, payments, adjustments — gets processed, posted, and accounted for during COB. If COB completes successfully, you know that the system has processed everything it was supposed to process. If it does not, you know that something is wrong, but you do not yet know how wrong.

If COB does not complete, you have a problem. Transactions may not have been posted. Balances may not have been updated. Reports may not have been generated. And until COB is resolved, the system cannot move to the next business day. This is also the point at which someone will ask you "can we just run it again?" and you will have to explain that COB is not a video game and you cannot just press continue.

This is why COB failures tend to escalate quickly. A failed COB means the business day cannot close, which means the next day cannot open, which means customers are affected, reports are late, and regulators start asking questions. It is also why the person who asks "is COB done yet?" every thirty seconds is usually not a developer.

What can go wrong

COB failures fall into a few broad categories. You will become familiar with all of them eventually:

• Job failures — a specific batch job crashes or returns an error code. This is the most common type of failure and usually the easiest to fix. It is also the one that makes you feel competent for about ten minutes until the next one hits.
• Timeouts — a job runs longer than its allocated window, causing the entire COB sequence to overrun. This is usually caused by data volume that has grown faster than anyone expected, or by a query that was efficient six months ago and is now a disaster.
• Resource exhaustion — the system runs out of memory, disk space, or database connections during processing. The classic sign of this is a log file that ends mid-sentence, followed by a support call that starts with "is the server still running?"
• Data inconsistencies — a record is in an unexpected state, causing a job to fail or produce incorrect results. This is the category that keeps you humble, because the data was fine yesterday and nobody changed anything. Except someone did, and they forgot to tell you.
• Locking conflicts — a record is locked by another process, preventing COB from accessing it. This usually means someone left a session open. Finding out who is a separate problem.

The key skill in handling COB failures is knowing how to read the COB log, identify which job failed, understand why it failed, and decide whether to restart it, skip it, or escalate. The secondary skill is knowing how to explain what happened in a way that does not make you sound like you are making excuses.

COB and AA

If your installation uses Arrangement Architecture (AA), COB becomes significantly more complex. AA introduces its own batch processing layer that handles activity scheduling, reverse-replay, and arrangement-level calculations during COB. It also introduces a whole new set of failure modes that will make you nostalgic for the days when COB failures were simple things like "the disk ran out of space."

This is covered in detail in the separate article on COB and AA: Why Activities Replay and When That Goes Wrong. For the purposes of this introduction, the important thing to know is that AA adds a significant amount of processing to COB, and that AA-related COB failures often require a different diagnostic approach. Also, the word "reverse-replay" sounds like a feature but it is usually the beginning of a long night.

What COB is not

It is worth being clear about what COB is not, because these misunderstandings cause a lot of confusion — and occasionally, very awkward conversations:

• COB is not a backup. COB processes data. It does not back it up. Backups should happen before or after COB, not during it. If you are relying on COB to protect you from data loss, you are going to have a bad time.
• COB is not a system restart. COB runs while the system is in batch mode. It does not restart the application or the database. If the database is in a bad state before COB, it will still be in a bad state after COB — just with more entries.
• COB is not a fix for data problems. If data is inconsistent before COB, running COB will not fix it. It will probably make the problem more visible, but it will not correct it. This is the technical equivalent of sweeping dust under a rug and being surprised when there is a bump.
• COB is not optional. You cannot skip COB and expect the system to work correctly. Every business day must have a completed COB. This seems obvious, but you would be surprised how many times someone has asked "can we just skip it tonight and catch up tomorrow?" No. No, you cannot.

What to do when COB fails

When COB fails, the first thing to do is stay calm. COB failures are routine. Every T24 environment has them. The question is not whether they happen, but how quickly you can diagnose and resolve them — and whether you can do it before the person who asks "is it fixed yet?" calls again.

The basic approach is:

1. Identify the failing job. The COB log will tell you which job failed and why. Read the error message carefully. It is probably not as cryptic as it looks. It is probably slightly more cryptic than it looks.
2. Determine the impact. Is this a job that can be restarted, or does it block everything else? If it blocks everything else, you have found the critical path. Congratulations. You are now the most important person in the room.
3. Fix the root cause. Most COB failures are caused by data issues — a missing record, an incorrect value, a locking conflict. Fix the data, not the symptom. Fixing the symptom is how you end up with the same failure tomorrow night.
4. Restart the job. Most COB frameworks allow individual jobs to be restarted without rerunning the entire sequence. If yours does not, you have my sympathy.
5. Verify completion. Once the job completes, verify that the rest of the COB sequence runs to completion. Then verify again. Then send the email that says "COB completed successfully" and try to get some sleep before tomorrow's COB.

The most important rule is: do not rush. A rushed COB recovery is how data gets corrupted. Take the time to understand what went wrong before you try to fix it. The person standing behind you can wait. They have been standing there for five minutes already. Another five will not kill them.

The bottom line

COB is the heartbeat of a T24 environment. It is the process that turns a day's worth of activity into a completed business day. Understanding what it does, what can go wrong, and how to respond when it does is one of the most valuable skills you can develop in a T24 support role. It is also the skill that determines whether you go home at a reasonable hour or whether you are still in the office at 3am eating a vending machine sandwich and wondering where it all went wrong.

The good news is that COB is not mysterious. It is a sequence of jobs, each with a clear purpose and a clear failure mode. Once you understand the sequence, you can diagnose most COB problems in minutes rather than hours. The bad news is that there is always one more failure mode you have not seen yet. That is what makes the job interesting. Or exhausting. Usually both.