AML notices in XML: the most common format errors and how to prevent them with automated validation

The notices (avisos) required by the LFPIORPI, Mexico's anti-money-laundering law, are filed with the SAT as XML files that must comply with the schema published for each vulnerable activity. In practice, many of those files are produced with Excel templates, exports from other systems or manual edits, and that is where problems appear. A notice can be correct in substance and still fail to be accepted because of a format detail, or be accepted with inconsistent data. After reviewing real notice files in our compliance projects, these are the errors we see most often and how we prevent them.

1. Postal codes without the leading zero

Mexican postal codes always have five digits. Those in Mexico City, for example, start with zero. When a postal code goes through a spreadsheet that reads it as a number, the leading zero disappears and the file ends up with four digits.

The error is silent: on screen the value looks right and nobody checks it. It also tends to repeat in every address of the same notice, because it originates in the template column rather than in a single record.

How to prevent it:

• Treat the postal code as text throughout the flow, from data capture to XML generation.
• Validate that it has exactly five digits and that it exists in the current postal code catalog.
• Check that the postal code is consistent with the declared state and neighborhood.

2. Amounts and quantities with inconsistent formatting

The second group of errors involves numbers. The most common:

• Amounts written as integers in a file where every other value has two decimals.
• Thousands separators, currency symbols or a comma as the decimal separator.
• Digits lost when re-entering or converting an amount, which produces a file that is valid in form but carries the wrong figure.

This last case is the most delicate, because no schema validation catches it: a number missing a zero is still a valid number.

How to prevent it:

• Set a single format for all amounts: decimal point, two decimals, no thousands separators or symbols.
• Generate the XML from the source data, not from a manually re-entered copy.
• Reconcile totals: the sum of the operations in the notice must match the sum recorded in the source system.

3. Dates and reported month

Each notice declares a reported month and contains the dates of the operations. Typical errors are of two kinds:

• Format: dates with dashes or slashes, or in day-month-year order, when the schema expects a continuous numeric string in the order it defines.
• Consistency: a reported month that bears no relation to the dates of the operations included.

Not every difference between the reported month and an operation date is an error; it depends on the rule that applies to the type of notice, for example when the threshold is reached by accumulating operations over several months. That is why good validation does not correct the month automatically: it flags the discrepancy and asks for it to be confirmed against the source information.

Automated validation does not replace the judgment of whoever files the notice; what it does is make sure that judgment is applied to a file free of format errors.

4. Catalog codes, text fields and identifiers

Much of a notice's content is expressed through catalog codes: type of operation, alert type, priority, country, currency, state, economic activity, monetary instrument. The usual errors:

• Using the description instead of the code, or a code from an earlier version of the catalog.
• Text with accents, lowercase letters or characters the field's pattern does not allow.
• RFC (tax ID) or CURP (population registry key) with an invalid structure, or inconsistent with the declared date of birth or incorporation.
• Internal references duplicated across notices, or declared counts that do not match the actual number of records included.

How to prevent it:

• Pull catalogs from an up-to-date source tied to the schema version, instead of copying them into every template. At AmigoApi we publish the LFPIORPI catalogs for this purpose.
• Normalize text before generating the file, according to the pattern each field requires.
• Apply cross-field rules, such as consistency between CURP and date of birth.

5. Validate in layers, before filing

The most reliable way to avoid rejections is to validate the notice in several layers and to do so before generating the final file, not after a failed upload:

1. Schema: validate the XML against the official XSD for the corresponding version. This catches missing elements, wrong ordering and invalid data types.
2. Patterns: check each field against its regular expression: length, allowed characters, RFC and CURP structure.
3. Cross-field rules: check consistency between fields and against the current catalogs.
4. Reconciliation: compare totals, counts and references with the source system.

Each layer should report the error in terms of the business data, for example the address of a specific client, and not only as a technical path inside the XML. That way, whoever fixes it knows exactly which record to edit. It is also worth pinning the schema version each file was generated with, because the SAT updates formats and a file valid for one version may not be valid for the next.

This is the approach we apply in the compliance platforms we develop: no notice is generated without first passing all four layers.

If your team generates notices and you want to automate their validation, Write to us.