LFPIORPI notices and XML in SPPLD: schedule, formats and quality control

Is an LFPIORPI Notice the same as an unusual transaction report?

The ordinary notice is triggered by activity and amount or accumulation. The 24-hour notice starts from suspicion or facts and indicia. The zero-activity report communicates that there were no reportable transactions under the applicable rule. Each one requires a documented decision.

The internal taxonomy must avoid ambiguous terms such as "ROS" for everything. It is advisable to use the legal name, platform, legal basis and process owner. When a group has a financial entity and a Vulnerable Activity, there may be two reports on related facts, but they do not replace each other.

The master control records regime, transaction, date of knowledge, due date, filing and acknowledgment. This prevents thinking that a submission in SITI satisfied an obligation in SPPLD.

How to put it into practice

For a shared fact, open related but separate files. Each party decides under its own regulations, protects confidentiality and retains its own evidence. The control must allow teams to collaborate without copying conclusions or unnecessary personal data. Test the schedule with three scenarios: a transaction that crosses the threshold, suspicion without a carried-out transaction, and a month without reportable transactions. If all three end in the same flow or deadline, the design needs to be corrected.

Legal basis

articles 18, section VI, 23 and 24 of the LFPIORPI and SPPLD Portal.

Why are DIN and INM not interchangeable?

The file must separate land, development, marketing, promise, sale-purchase, assignment and receipt of funds. The same company may hold more than one role. The relevant date and amount may also differ depending on the act.

Before generating the XML, a classification sheet is prepared with: the section of article 17, the obligated party's role, contract, property, client, form of payment and reportable event. That sheet justifies why DIN or INM was used.

The portal catalogs are part of the control. A technically accepted code may poorly describe the transaction. For this reason legal validates classification and data validates structure.

How to put it into practice

Use test cases that include the same company with two roles and a payment linked to several stages. Legal approves the classification; data verifies that the field comes from the correct source; compliance checks threshold and filing. Retain the version of the annex, instructions and catalog used, because a later change must not rewrite the historical explanation. If there is doubt between formats, do not resolve it by testing which one the portal accepts: technical acceptance does not validate the legal characterization.

Legal basis

real estate activities under article 17 of the LFPIORPI and official SPPLD instructions.

Which errors in dates, RFC, CURP and catalogs cause rejections?

The control must validate structure and semantics. The structure reviews XSD, lengths, type and mandatory nature. The semantics compares data against the file, contract, supporting document and transaction. An identifier must not be "corrected" to pass the portal without going back to the source.

The catalog tables are versioned with a download date. If the portal changes a code, the system preserves which one was used in each notice. Manual corrections are logged with the requester and approver.

An exceptions file allows handling homonyms, foreigners without a CURP or special legal figures without filling fields with fictitious data.

How to put it into practice

Implement rules at three levels. The first checks type, length and format; the second cross-checks related fields—legal entity versus RFC, country versus state, currency versus amount; the third compares against the source document. In anonymized presentations, a valid date passed XSD but corresponded to the ERP entry and not to the reportable act. The portal could not detect that error; only legal reconciliation revealed it.

Each manual correction must record the original value, new value, source, requester and approver. Keep catalogs with a hash or version and effective date. Test accented characters, foreign names, legitimate absence of CURP, postal codes and deadline dates. For exceptions, use an approved flow that does not invent data: document why the field does not exist and how the applicable instructions require it to be captured. After submission, analyze rejections by cause and source system; correcting only the XML perpetuates the defect in the next period.

Legal basis

SPPLD technical recommendations and official instructions and schemas.

How do you detect reportable real estate transactions?

The process begins with the inventory of contracts and not with the XML. For each record, the company's role, type of act, stage and payments are identified. The client and development are normalized; then threshold and accumulation are applied.

Real estate databases often have data scattered among sales, treasury and legal. The reconciliation must detect contracts without payment, payments without a contract, duplicate clients, changes of title holder and assignments. Each discrepancy is resolved before submission.

The dashboard distinguishes "potentially reportable," "legal validation," "ready," "filed" and "corrected." A binary filter does not capture the necessary investigation.

How to put it into practice

Build a ledger by movement with independent identifiers for client, contract, unit and property. Reconcile at least three sources: legal's contracts, treasury's collections and sales' title holding. In anonymized data, deposits without a reference were applied days later; if the calculation used the application date, it could move transactions between periods. The policy must define the legal event and preserve both the bank date and the posting date.

Run integrity controls: contract without collection, collection without contract, duplicate unit, assignment without client update, unlinked refund and third-party payment. Each exception is resolved before the "ready" status. The review sheet includes section, format, UMA, accumulated transactions, CB and an explanation of the means of payment. Also sample discarded transactions, since a dashboard of positives alone does not reveal coverage failures. Traceability must allow going from the acknowledgment to the property and back from any payment to the reporting decision.

Legal basis

article 17 of the LFPIORPI in force and SPPLD formats.

Which UMA must be used and why does the date matter?

The database must store the multiplier, daily UMA, peso equivalent, date and result. This prevents an annual change from altering historical records. In contracts with successive payments, the policy defines which event is assessed and how it accumulates.

It is not advisable to round before finishing the calculation. Decimals are preserved and the comparison rule is documented. The figures published in a guide are a reference; the system obtains the official value in force and subjects it to annual control.

The date should also not always be inferred from the upload to the ERP. Contract, invoice, payment and legal act may occur at different moments. Legal determines the event; data retains the fields.

How to put it into practice

Manage the UMA as a table with valid-from/valid-to dates and dual approval, not as a constant in the code. The calculation must select the value by the event date, preserve decimals and display the formula. In anonymized engines, updating the annual parameter overwrote historical records and turned January transactions into false positives. A version record and a regression test on the change from January 31 to February 1 prevent that alteration.

Prepare cases exactly below, equal to and above the threshold, plus accumulation that ends up exactly equal and another that exceeds it. Do not confuse the individual comparison framed as "equal to or greater than" with the accumulation rule "exceeds." If the transaction is in a foreign currency, also document the exchange rate required by the applicable regime and its source. The calculation report must allow another person to reproduce the result without accessing the source code.

Legal basis

2026 UMA published by INEGI and thresholds under article 17 of the LFPIORPI.

How are the ordinary notice, zero-activity report and 24-hour notice distinguished?

The schedule must handle dates of different natures. For ordinary notices, transaction and period. For 24-hour notices, the documented moment of knowledge or of suspicion arising. For zero-activity reports, closing and validation that there were no transactions.

A 24-hour notice must not be generated merely because a client is high risk. Facts, indicia and analysis are documented. Nor is it delayed to await the monthly close.

The procedure must protect the confidentiality of the analysis and limit access. The log records who escalated, the information considered and the decision, without disclosing it to the client.

How to put it into practice

Set up three queues. The monthly one receives classified and reconciled transactions; the zero-activity one requires the data owner to certify coverage before declaring absence; the urgent one records the moment of knowledge, facts and escalation. In anonymized practices, the urgent alert landed in an inbox designed for the monthly close because both were called "notice." Naming the obligation and displaying a visible counter reduces the deadline risk.

Do not use high risk as a substitute for indicia nor await criminal certainty. The analyst documents facts, sources and reasoning, and the approver decides under the applicable standard. Limit access and communications so as not to alert the client. For the zero-activity report, reconcile population, sources and exceptions; "the system generated no alerts" is not sufficient evidence if an interface was missing. Retain the filing and acknowledgment, and link the ordinary notice with the individual transactions that support it.

The urgent log must record the time zone and the exact moment of knowledge so that the 24-hour computation can be reproduced.

Legal basis

articles 18, section VI, and 23 of the LFPIORPI, plus SPPLD obligations.

Why are real estate development and sale-purchase controlled separately?

The developer must not assume that the notary will file every relevant notice. The public officer fulfills its obligations with respect to its acts; the company retains its own. Nor must a notice be automatically duplicated without reviewing which activity and party are reported.

The per-project matrix identifies the owning vehicle, developer, marketer, trustee and public officer. It assigns activity, evidence and person responsible. This way one can explain why the same payment appears in different controls without confusing duplication with concurrent obligations.

The contracts must clearly reflect who receives funds and for what purpose. The regulatory database cannot compensate for an opaque contractual flow.

How to put it into practice

Create a RACI matrix per project: owning vehicle, developer, marketer, trustee, buyer and public officer. For each flow indicate the contract, receiving account, purpose, potential activity, source document and person responsible for analyzing it. In anonymized projects, the marketer received deposits into a concentrator account and transferred them to the vehicle; both records looked like independent sales until they were linked through a reference number. The architecture must preserve the movement without counting it twice as a separate act.

Before opening sales, test advance, assignment, cancellation, refund, notarization and third-party payment. Verify which team updates title holding and how the change is communicated to compliance. Do not base the control solely on the deed: the receipt of funds may occur earlier. At the same time, do not presume that every advance is reportable without applying the correct section, threshold and accumulation. Concluding by flow avoids both omissions and defensive duplications that degrade the quality of the notices.

Legal basis

real estate cases under article 17 of the LFPIORPI and SPPLD instructions.

Why can grouping transactions destroy traceability?

The correct architecture keeps an immutable ledger of movements and a calculated view of cumulative totals. If a movement is corrected, a reversal or version is recorded; it is not silently replaced. The notice retains a reference to the rows that originated it.

Grouping by client requires a reliable identifier. A name or RFC captured with variations may improperly split or merge. Deduplication is reviewed before calculating.

For audit purposes, one must be able to answer: which transactions make up this amount, why they belong to the same client, which UMA was used and which file was submitted.

How to put it into practice

Assign each movement a stable ID and the notice a package ID. A bridge table relates the two and stores the version of the calculation. In anonymized data, a monthly total was later distributed among clients through a manual sheet; when a row was modified, it no longer matched the accepted XML. Freezing the submitted package, its hash and the component rows solved the reconstruction without preventing future adjustments.

Deduplication needs identity controls: RFC where it exists, internal identifiers, date of birth or incorporation and a review of matches. Do not group by name alone nor split by branch. Test reversals, partial payments and changes of title holder. For each notice, produce a reproducible report with parameters, transactions, exclusions and approver. When correcting, retain the prior calculation and show the difference. Traceability protects both against omission and against over-reporting caused by adding the same flow twice.

A final reconciliation must demonstrate that no component row remained simultaneously linked to two incompatible packages.

Legal basis

the duty to retain and reconstruct transactions under article 18 of the LFPIORPI in force.

When does an error require an amending notice?

The policy classifies material and formal errors. Wrong client, amount, Controlling Beneficiary or type of transaction affect the content. A character or catalog may be formal, but it is not minimized without analysis.

The correction file contains the original notice, acknowledgment, finding, correct source, approval, new file and subsequent acknowledgment. The wrong version is never deleted.

Repeated changes are a sign of root cause: an outdated catalog, a manual interface, a lack of validation or defective master data. The closure includes remediation of the process.

How to put it into practice

Classify the incident before acting: rejection without receipt; acceptance with an incorrect formal datum; acceptance with an incorrect material datum; or duplication. Consult the instructions in force and document the path. In anonymized corrections, resubmitting an accepted file as if it were new produced duplication; the team had retained the XML but not the status or the acknowledgment reference number. The master control must prevent a second filing without expressly choosing its nature.

The materiality review considers client, amount, activity, CB, date and effect on accumulation. Even a single character may matter if it changes identity. After correcting, compare fields between versions and reconcile both acknowledgments. Open a root-cause analysis when the error could recur: interface, catalog, master data, training or review. The action does not end with "the portal accepted"; it ends when the file and the source system reflect the correct data without destroying history.

The responsible person must also review whether the incorrect datum contaminated other notices in the same batch or period; correcting only the discovered case may leave an identical population unaddressed.

Legal basis

article 24 of the LFPIORPI and official SPPLD instructions.

What quality control must be run before submission?

Pre-submission checklist

• current version of format, catalog and XSD;
• correct party and activity;
• consistent client, representative and Controlling Beneficiary;
• date, amount, currency and form of payment cross-checked;
• reproducible accumulation;
• conditional fields completed;
• valid characters and lengths;
• sample review against documents;
• file, hash and approver recorded;
• acknowledgment downloaded and linked.

The subsequent reconciliation verifies accepted, rejected, pending and amending notices. A generated file is not equivalent to a filed notice.

How to put it into practice

Segregate functions: whoever extracts data should not approve the classification alone, and whoever uploads should not close the control without reconciling. In anonymized batches, the file passed XSD but omitted an entire source because the count was compared against the same defective extraction. The reconciliation needs an independent population: a ledger or transaction control, not another output of the generator.

Record totals by activity, period, clients, transactions and amount; explain differences from the previous period. The sample must cover the largest amount, the limit, accumulation, a foreign person, a manual correction and a discarded transaction. After the upload, verify the portal's response, the acknowledgment and the hash match. If there is a rejection, freeze the version and open an incident; do not edit the file without a trail. This package makes it possible to demonstrate not only that it was filed, but that the population was complete and the data came from authorized evidence.

Also include a reconciliation of the period's users and privileges: it identifies uploads or adjustments made by inactive, shared or unauthorized accounts and requires reviewing their impact before closing.

Legal basis

SPPLD technical recommendations, SPPLD formats and article 24 of the LFPIORPI.