How to automate periodic reviews without automating the decision

Automate everything in a periodic review that is collection and comparison: finding the files that are due, refreshing registry data, re-running screening, chasing the customer for what has expired, and writing the trail. Keep one thing manual, the decision itself: confirm the relationship, change its risk level, or exit. That split clears most of the backlog and leaves the judgement where a supervisor will look for it.

This post sets out what the rules ask, which steps of a review belong to a machine, and how to build it in Dotfile with a routine that runs every night and stops short of the decision.

What the rules ask

The EU Anti-Money Laundering Regulation, which applies from 10 July 2027, turns "keep customer information up to date" into a deadline. Under Article 26(2) of Regulation (EU) 2024/1624, the period between updates depends on risk and "shall not in any case exceed" 1 year for higher-risk customers under enhanced due diligence, and 5 years for all other customers.

The calendar is only half of it. Article 26(3) also requires a review when there is a change in the relevant circumstances of a customer, or when you become aware of a relevant fact about them. A review policy that only runs on dates misses the director who resigned last Tuesday.

The detail is coming. Article 26(5) asked AMLA to issue guidelines on ongoing monitoring, and AMLA consulted on a draft from 3 June to 3 September 2026, with one guideline dedicated to keeping customer information up to date. The final text had not been published when we wrote this, in October 2026. The ceilings above are in the Regulation itself and will not move.

Why periodic review turns into a backlog

A periodic review is mostly repeated onboarding. The same registry extract, the same screening, the same request for a fresh proof of address, for a file someone approved one to five years ago. Reviews come due in batches that follow past onboarding volumes, not this quarter's staffing, so they pile up exactly when the team is busy with new customers.

And an overdue review is easy for a supervisor to find, because the due date sits in your own system.

The split: what to automate, what to keep

The last row is the one that matters. A review that a machine opened, collected, compared and closed on its own is not a review anyone can defend. A review where the machine did the collecting and the analyst opened a file that says "two things changed, here they are" is a better review than most teams run today.

Building it in Dotfile

1. Set review periods by risk level

In the approval flow settings, periodic review periods are set per risk level: for example, high-risk cases every year and low-risk cases every two. The next review date is counted from the approval date, or from the last review. Under AMLR, the high-risk period cannot exceed one year and none can exceed five.

2. Watch for changes between reviews

Company monitoring covers Article 26(3) on the company side. Choose the categories you care about (directors, shareholders, status, registered office, financial events) and any change sends the check back to Need Review. Add the check to your templates so every new case starts monitored. Coverage depends on the registry behind each country, and the doc page lists it.

3. Write the routine

A routine is a prompt that Autonomy runs without you, on a schedule, on an event in your workspace, or on a call from your own systems. Brief it the way you would brief a colleague covering for you. A nightly periodic review sweep might read:

Find every approved case whose periodic review is due in the next 14 days or already overdue. For each one, refresh the company data and report only what changed, relaunch the checks that have gone stale, and chase the contacts for any document that has expired. Write a note on the case listing what you relaunched and why. Do not complete the review. End with a list of the cases that need a person, and say why for each one.

Give it a Schedule trigger (daily, weekly on chosen days, or monthly, at a time and timezone you pick), or an Event trigger from the same catalogue as webhooks. Type `/` to build on a ready-made skill such as `/refresh-company` or `/chase-contact` instead of writing every step yourself.

4. Run it once by hand, then read the run

Run the routine on demand from its menu before putting it on a schedule. Every run is kept with what fired it, the tools the agent called, the outcome per case and the report it wrote at the end, so you can see which cases it touched, which it skipped and why. This is where a routine earns your trust or loses it.

5. Keep the permissions tight

Routines have their own permissions, separate from the right to chat with Autonomy: view, create, edit and delete, set per role. Members restricted to a space do not see them, because a routine runs headless and can reach beyond a single space. Any AI review it launches follows the AI Policies you wrote, one per check type, and records its reasoning on the check.

What the analyst opens in the morning

Instead of a list of due dates, a list of files that have already been worked: fresh registry data, the differences called out, screening re-run, the customer already chased, a note saying what was done. What remains is the part that needs a person, and it is the part an auditor will ask about.

Skills and Routines are available in every Dotfile workspace as part of Autonomy. Read the documentation to write your first routine.