The automation is the easy part. Reconstructing why the system did what it did, two years later, is the part that has to be designed in.
An examiner asks why a particular account was traded on a particular day. The answer has to be findable, specific, and consistent with your stated process.
If the answer is "the system did it," you have an automation that works and a record that does not.
Most systems record what happened. Fewer record why — which rule fired, what the inputs were, what threshold was crossed.
The reason is the part you will need, and it is the part that is impossible to reconstruct after the fact.
The stated process and the implemented process have to match. Where they drift, the automation is doing something your documented programme does not describe, which is worse than doing it manually.
An automation that cannot explain itself has moved your risk rather than reducing it.
Every automated process has accounts that fall out of it. What happens to them, who reviews them, and whether that review is recorded is the part that gets designed last and examined first.
When a rule changes, the old one still governs everything it did before. Keeping dated versions of the logic is the only way to explain a decision made under a rule that no longer exists.
An automation that silently stops running is worse than one that never ran, because everyone believes it is working. Build an alert for the absence of activity, not just for errors.
This is the same principle as verifying a live site rather than trusting a build: correctness at the time you built it proves nothing about today.