AMLA customer counts: explain the change from records to report

By Alexander Akkarie. Content reviewed on 26 October 2026.

Explain an AMLA customer-count correction with a bridge from the filed number to the reporting population required by the instructions. Show what was omitted, why each addition belongs and how duplicates were removed. Keep changes from a later reference period separate. For a Luxembourg firm, that gives the RC or RR something specific to approve before a changed number goes to the home supervisor.

A new template version is a different issue. AMLA says a firm that already submitted V1.1 does not need to resubmit merely because V1.2 is available. Its planned correction phase addresses data errors through home supervisors. AMLA's collection and correction notice

A template-version change and a population error need different decisions. Preserve the exercise, reference period, template version and interpretation used before changing either the data or the return.

Do not refile because the template number changed

For Luxembourg, the first collection deadline under Circular 26/914 was 22 July 2026. The circular places responsibility for the submission and its adequacy with the RC or RR, even where preparation is delegated. CSSF Circular 26/914

After filing, a data specialist may find that the customer extract used the wrong filter. That deserves a correction assessment. Downloading a newer spreadsheet does not, on its own, demonstrate an error.

Preserve the filed return before recalculating it. If the team overwrites the original number and its supporting extract, it loses the most useful part of the explanation: the difference between the answer sent and the answer now proposed.

Build the bridge from the definition, not today's list

For the 2026 collection, AMLA's FAQ includes customers with a business relationship at any time during 2025 or at least one occasional transaction during that year, including relationships closed before year end. For the country field discussed here, individuals are allocated by residence rather than nationality; legal-entity residence is interpreted as country of establishment. AMLA FAQ, customer and residence questions

Consider a hypothetical solo Luxembourg investment firm providing services to customers resident in France. The original extract counted only customers marked active at year end. The team then rebuilds the required 2025 population from retained records.

For this example, each customer belongs to only one of the four groups below. Customer identities have been deduplicated within the entity, residence has been checked for the relevant reporting population, and the dormant and closed relationships and occasional transactions qualify under the instructions. These are assumptions to test in a real correction, not facts about a real firm.

The arithmetic is straightforward: 720 + 610 + 180 = 1,510; 18,900 + 1,510 = 20,410. The harder check is whether those sets really are separate. A customer whose relationship closed during the year must not also be added again as an occasional-transaction-only customer.

My analysis: the bridge is more useful than a second total. It exposes the selection logic that changed the answer. A reviewer can challenge the 610 closed relationships or the residence allocation without rejecting the entire exercise as unexplained.

Prove the rule on a small record set

The aggregate bridge assumes that identity matching and inclusion have already been done correctly. Test those assumptions on records. The separate miniature example below uses eight invented source rows for the same solo investment-firm and country scope. Its counts do not form part of the 20,410 example.

The filed extract contains C001 and C002: two customers. The corrected, confirmed set contains C001 to C005: five. The movement is three confirmed additions, not four source rows. R05 supports an existing member of the set; it does not create a second C004.

R08 prevents the reviewer from declaring the population fully resolved. It could match one of the five, identify another qualifying customer or fall outside the country scope once evidence is checked. Record “five confirmed, one source row unresolved”, assign an owner and obtain the missing evidence. Do not silently discard the row or guess that the final answer is six. If a reporting deadline arrives first, the authorised reporting owner must determine the treatment under the applicable instructions and supervisor route.

Use a stable entity-and-customer key supported by the firm's identity controls. A matching name alone is weak evidence, particularly where two people share a name or a legal entity has changed its name. Keep the source-row-to-customer mapping so a reviewer can reverse the aggregation and see every inclusion or exclusion.

For C003, assume the current master shows Germany following a move in 2026, while the retained evidence supports France for the 2025 population in this example. Preserve the historical basis and have the reporting owner confirm the applicable reference rule. Overwriting it with today's field would change the country result without changing the underlying 2025 relationship.

For each group, retain the customer identifiers, the qualifying relationship or transaction evidence, the country evidence and the inclusion rule. Keep those records privately; the example workbook needs no personal data.

Do not use today's customer master as a shortcut. A later status change can make a 2025 relationship disappear from the current active list. A residence field updated in 2026 can also obscure the basis used for the earlier period. The correction must be explainable from the relevant historical evidence, not just reproducible from the latest screen.

A checked count is not an eligibility verdict

The corrected 20,410 answers one reporting-population question for one entity and one country. It does not establish the firm's wider cross-border eligibility or its eventual selection for direct supervision. AMLA's FAQ addresses the broader country and organisational questions separately.

Do not turn the size of the corrected count into a shortcut for that assessment. The annual population definition, applicable reference points, other activity measures and the firm's wider perimeter still matter.

Use the correct counting unit for fund managers

The investment-firm example should not be copied into an AIFM or UCITS-manager return. AMLA's FAQ questions 45 and 46 give a specific fund-investor rule: the person in the CIU shares or units register is counted once per CIU, including active, inactive and dormant holders. Multiple positions in the same CIU do not create multiple customers. AMLA FAQ, questions 45-46

The three positions produce two distinct CIU-customer pairs. Counting globally distinct investor IDs would give one and lose the per-CIU instruction; counting positions would give three and duplicate CIU-A. Neither is the illustrated rule. Additional services or a more complex reporting perimeter need their own instruction check before these pairs are combined into a return.

Separate correction from the next reference period

The next collection is not simply a copy of the old file with the error removed. AMLA's August notice describes an early-2027 eligibility collection using a 31 December 2026 reference date. That notice presented a working draft. AMLA's August 2027-collection notice

There is now later official material. On 12 October 2026, the EBA published the final technical package for reporting framework 4.4, phase 1. It includes AMLA eligibility templates and revised templates supporting the 2027 risk-assessment collection. Use that current package when planning the next implementation; do not continue describing the August draft as the latest technical status. EBA's final 4.4 package announcement

The final technical package does not make today's customer list the right input for a historical correction. Keep a separate rule-and-version record for each exercise. Check the actual current instructions, reference points and national submission arrangements before transferring the 2025 logic to the next collection.

In the fictional firm's change log, three discoveries require different treatment:

This separation prevents the old correction from silently becoming a mixture of two reporting periods. It also makes the next collection easier to explain: a corrected historical input and a later business change remain visible as different movements.

Approve the explanation before changing the submission

Subject to the explicit non-overlap and evidence assumptions in the large example, the prepared answer is 20,410. The smaller record example remains at five confirmed customers with one unresolved source row, so it is not ready for an unqualified final-count approval. For the large example, the approval record can state: 1,510 additional unique customers; four non-overlapping groups; 2025 evidence retained; residence basis checked; wider eligibility assessment outside this calculation. The RC or RR can then review a defined change rather than an unexplained replacement number.

The example remains unsubmitted until the authorised person approves it and the home-supervisor route is confirmed. Neither the original collection deadline nor the existence of an eDesk campaign establishes that a particular correction channel is currently open. AMLA's notice places correction handling with home supervisors; use their current instructions.

Keep the original return, proposed corrected version, bridge, approval and eventual submission reference together. In this case, the useful result is not merely “20,410 is now in a spreadsheet”. It is an explanation of why 18,900 was incomplete, what changed, and why the 2026 acquisition did not enter the same correction.

The completed workbook keeps both examples separate. Use the record-level sheet to check inclusions and overlaps before using the aggregate bridge in an approval discussion. It contains static values for manual review; it does not perform automated identity matching or determine eligibility.

Companion workbook

A completed record-level bridge exposes overlapping source rows, exclusions and unresolved identities, then distinguishes entity counts from CIU-customer pairs.

• Download the editable Excel workbook

• Download the PDF