AA fundamentals
COB and AA: Why Activities Replay and When That Goes Wrong
Reverse-replay is one of the most powerful features in AA and one of the most common sources of production incidents. Understanding what triggers it, what it does, and what it looks like when it fails turns a confusing problem into a diagnosable one.
The call usually goes something like this: a change was made to an arrangement — a rate amendment, a product condition update, something routine. The next morning, the arrangement is in a state that nobody expected. Balances are different. The accounting entries look odd. Something happened during COB and nobody is quite sure what.
What happened was reverse-replay. The system unwound the arrangement's entire history from the effective date of the change, rebuilt it with the new conditions applied, and produced a different result. This is exactly what it is supposed to do. The question is whether you expected it to happen, and whether it completed correctly.
What happens during COB in AA
Every night, COB processes active arrangements. For each arrangement, this involves a set of Activities — accrual of interest, checking payment schedules, applying charges, updating overdue statuses, and more.
Each Activity generates a set of Actions. Actions produce accounting entries, update balances, send notifications, trigger downstream processes. The result of a day's COB for an arrangement is recorded as a set of Activity records —AA.ARRANGEMENT.ACTIVITY — that form a complete audit trail of everything that happened.
Normally this is straightforward. The arrangement exists, today's activities run, new records are created, the day is done.
Reverse-replay is what happens when something changes retroactively.
What triggers reverse-replay
Any change with an effective date in the past triggers reverse-replay for the affected arrangement. Common triggers:
- A back-dated rate amendment on an arrangement
- A product condition change that is published with a past effective date
- Adding a new property to existing arrangements with a start date of “Today” or earlier
- A back-dated activity such as a correction or reversal initiated by operations
- A manual amendment to an arrangement condition with an effective date before today
The common thread: the arrangement's history needs to be recalculated from the point where something changed. AA handles this by reversing everything that happened from that point forward, then replaying it with the new conditions in place.
What reverse-replay actually does
The process has three stages:
1. Reverse — the system works backwards from today to the effective date of the change. Every accounting entry that was generated from that date forward is reversed. Every Activity record from that date forward is unwound. The arrangement is returned to the state it was in at the effective date, as if everything that happened after that point never occurred.
2. Apply the change — the new condition is applied as of the effective date.
3. Replay — the system runs forward through every day from the effective date to today, regenerating all the Activities and accounting entries with the new conditions in place. Interest accruals, charges, payment events — everything is recalculated.
The result is a corrected arrangement whose history reflects what wouldhave happened if the new condition had been in place from the effective date. The accounting entries are net — the reversals and the new entries offset each other — but the balances, the accruals, and the activity records all reflect the corrected view.
Why it is the most common source of AA production incidents
Several things can go wrong with reverse-replay, and the symptoms are not always obvious.
It takes longer than expected
An arrangement with two years of daily accruals that needs to be replayed from six months ago has a lot of history to unwind and rebuild. On a portfolio with thousands of arrangements, a back-dated product condition change can turn a normal COB run into a very long one. Teams that apply a condition change without considering the replay volume sometimes discover this at 3am when COB has not finished.
It fails partway through
If something in the replay fails — a validation error, a data problem, an unexpected condition — the arrangement can be left in a partially processed state. The reversals have been applied but the replay has not completed. The arrangement's balances and accounting are in an inconsistent state.
This presents in the arrangement as unexpected balances, missing activity records, or accounting entries that do not reconcile. The arrangement may appear to be in a failed or error state. Depending on how the error is handled, it may surface in an exception queue or remain silently broken until someone notices the numbers are wrong.
It was not expected
Operations teams that are not aware of reverse-replay sometimes make a back-dated amendment expecting a small correction and are surprised when COB produces a large set of accounting adjustments. The adjustments are correct — they reflect the true impact of the back-dated change — but nobody communicated to finance that they would appear.
“Why are there all these accounting entries?” is a more common support call than it should be, and the answer is almost always: someone made a back-dated amendment and did not tell anyone what that would produce.
The warning was accepted without reading it
When you apply a back-dated condition in AA, the system displays an override warning: something along the lines of “It might trigger Reverse-Replay right from [date] in the existing arrangements.”
This override is routinely accepted without being read. It is not a soft warning. It is the system explaining exactly what is about to happen. The teams that understand AA read it and consider the implications. The teams that do not understand AA click through it and find out during the next COB.
How to diagnose a reverse-replay problem
When an arrangement has unexpected balances or accounting after COB, and you suspect reverse-replay:
- Check the arrangement's activity records for the period in question. Look for reversal activities — they will have negative accounting entries corresponding to the original positive ones.
- Find the effective date of the most recent condition change on the arrangement. That date is where the reverse-replay started.
- Check whether the replay completed. If there are reversals but no corresponding forward activities, the replay failed partway through.
- If replay failed: check what error or validation condition stopped it. This is usually visible in the arrangement audit trail or in the activity record that failed.
- Confirm the net accounting position. Reversals plus new entries should equal the expected outcome under the new conditions.
How to avoid the common mistakes
Before making any back-dated change: estimate the volume. How many arrangements will be affected? How many days of history will be replayed? If it is a large number, this is a conversation to have with the operations team before it becomes a COB performance problem.
Before publishing a product condition with a past effective date:understand the Add New Property options. Choosing “Start” means the replay goes back to the arrangement start date. Choosing “Today” means no replay. Choosing a specific past date means replay from that date. The choice matters.
When reverse-replay is expected to produce accounting entries:tell finance before it runs. Not after.
Read the override warnings. The system is not being cautious for the sake of it. It is telling you what is about to happen.