SOFOMs
SITI, reports, LPB, unusual transactions and evidence
Identity, chronology, role, subsequent activity and legal basis determine what to report. These microblogs offer trees, layouts and controls without turning an internal case into a public template.
Common method of the dossier
Reports are worked as evidentiary timelines. The file separates alert, knowledge, attempt or transaction, investigation, decision, approval, transmitted file and acknowledgment; it also preserves the version of the lists and data consulted. This sequence avoids choosing the type of report by intuition or drafting narratives that do not match fields and supporting documents. Quality control must be able to return from the acknowledgment to the source event and from the event to the conclusion of the competent body.
Decision and report transmission framework
The report file begins before the layout. First it freezes facts, identity, transaction, roles and chronology; then it identifies the rule and compares possible routes; finally it converts the decision into fields, narrative and file. This order prevents the internal name of the alert or an old template from determining the type. The 24-hour report, the ordinary ROI and EOPERATIVA may share data, but they have triggers, deadlines and structures that must be analyzed separately in accordance with the current source.
The chronology distinguishes transaction, detection, knowledge, query, decision and transmission. When a person appears later on a list, the analysis preserves dates and does not invent a subsequent attempt. Retrospective searches document period, systems, identifiers and limitations. A potential match is resolved with sufficient data before attributing identity. If the new information also makes the historical behavior relevant again, the corresponding analysis is opened without mixing the legal basis or deadline of the two routes.
The narrative is drafted from a table of facts. Each sentence identifies subject and source; amounts and dates are reconciled with the transaction; profile and alerts are described as of the cutoff date. PEP, impersonation and transactional deviation require different accounts because they change identity, evidence and risk. Fields 35 and 36 are used according to the instructions, without duplicating text or filling gaps by inference. An independent reader must understand what happened, why it was analyzed and what information was available.
The layout is controlled by version. Each column links source data, transformation, catalog, validation and owner. Test cases cover valid format, conditioned field, deadline date, invalid character and prior catalog. Technical acceptance does not prove substantive accuracy: another sample returns from the file to the case file and transaction. The approved base is frozen; any correction generates a new version, explanation and second approval. The exact file, hash, folio, response and reconciliation remain together.
Audit reconstructs reports, dismissals and corrections. It recalculates deadlines, confirms identity, traces amounts and verifies that the transmitted version matches the approved one. Errors are classified by data, transformation, criterion or capture and the affected population is sought. Metrics include differences between narrative and base, rejections, unreconciled folios and incomplete case files. This framework allows testing the quality of the process and does not confuse volume of submissions with effective compliance.
Recipient third party later added to the LPB
Confirm identity: a similar name is not enough. Review balance, new instruction, payments, relationships and any subsequent attempt. Separate the obligation toward the client from the analysis of the third party.
How to put it into practice
identity; relationship; instruction; transaction; inclusion; knowledge; subsequent search; balance; analysis; decision; report; measure. Preserve the official source and negative evidence of the search. Do not attribute criminal intent.
Subsequent fact and scope of the match. If a recipient third party later appears on a list of blocked persons, the SOFOM must establish when it learned the identity, what transaction occurred, what match was confirmed and what the relevant publication was. A transfer already executed before the listing is not reconstructed as a "subsequent attempt." The chronology separates transaction date, list registration date, detection and internal decision.
The analysis verifies name, identifiers, account, role and link with the client to rule out homonymy. It then reviews the obligations applicable at the moment of knowledge and whether the facts also warrant study as an unusual transaction. The file preserves the official query, data capture, transaction, alerts, reasoning and any report or determination. A system test introduces the third party into the catalog after the transaction and observes whether retrospective monitoring generates a case without altering dates. The CO documents alternatives and legal basis, and the transmitted file must match the narrative. This is how supervening data is correctly handled without inventing conduct or omitting an independent evaluation of the pattern.
Legal basis
24-hour report vs. unusual transaction
Build a tree: confirmed match; date; relationship; transaction/attempt; balance; conduct; indicator; analysis; type; deadline. Record when each fact became known. For the 24-hour report vs. unusual transaction, the test is limited to its own data, decision and supporting documents.
Observed pattern. Defensible cases show the alternative considered and why it was discarded. That demonstrates reasoning, not automatism. For the 24-hour report vs. unusual transaction, the test is limited to its own data, decision and supporting documents.
How to put it into practice
event record; chronology; query; profile; evidence; legal basis; CO/body decision; file; review; folio; follow-up. If the information is incomplete and a deadline is running, document reasonable measures and escalate.
Two routes with different triggers. The 24-hour report responds to specific circumstances and to a moment of knowledge; the unusual transaction is analyzed by departure from profile, characteristics or signals in accordance with the ordinary process. A single fact may require reviewing both routes, but they must not be merged. The initial record freezes identity, transaction, chronology, query and legal basis before choosing the type of report.
Use one case with a confirmed match and another with anomalous behavior without a list. The analyst calculates deadlines from the relevant legal event, documents searches and prepares the narrative corresponding to each decision. If the information arrives later, it preserves when it was received and what prior facts it changes. The CO reviews consistency between type, fields, dates and account; a technically valid file may be substantively incorrect. The folder contains alert, queries, profile, deliberation, approval, layout, exact file, acknowledgment and follow-up. Metrics distinguish evaluated cases, reports of each class, dismissals and corrections, avoiding the use of volume as a substitute for quality.
Legal basis
CNBV, SOFOM E.N.R. regulations. For the 24-hour report vs. unusual transaction, the test is limited to its own data, decision and supporting documents. Verified reference for this topic. For the 24-hour report vs. unusual transaction, the test is limited to its own data, decision and supporting documents.
For the 24-hour report vs. unusual transaction, the test is limited to its own data, decision and supporting documents.
Drafting fields 35 and 36
How to put it into practice
Include parties, product, date, verified amount, profile, deviation, queries, explanation and measures. Distinguish "the client declared," "the SOFOM verified" and "it is inferred."
Observed pattern. Drafting a chronology first and then distributing it across fields reduces contradictions. Review by someone who did not investigate proves self-sufficiency.
Tool: who; what; when; how; profile; deviation; source; explanation; measure; conclusion. Remove adjectives and accusations; validate that dates and amounts match the layout.
Different functions of the narrative fields. Before drafting, confirm in the current instructions what information corresponds to fields 35 and 36 and how it relates to the type of report. The text must not be duplicated for convenience or contain conclusions that the structured file contradicts. A matrix separates who, what, when, how much, how it was detected and why it is relevant.
The narrative is built from chronology and evidence, using factual language. Identifiers are validated against the case file; amounts and dates against the transaction; the profile against information available at the cutoff. If there is a PEP, impersonation or list, the confirmed match is explained and not just the label. A second reviewer reads the text without knowing the case and flags ambiguities or gaps. Then each sentence is compared with the corresponding structured field and unnecessary information is removed. The folder preserves the draft version, comments, approval and transmitted file. This review avoids generic stories, repetitions between fields and assertions that could not be sustained in a subsequent inquiry.
Closing criterion. Create internal examples of a sufficient narrative and a defective one, using synthetic data. The training asks the analyst to correct chronology, subject and source, and preserves the result. This practice measures understanding of the instructions better than a template that merely invites replacing names and amounts.
Legal basis
Structuring a SITI layout
Map each field to the system. Define the treatment of unknown, zero and not applicable; they are not interchangeable. Use validations for date, currency, identifiers and consistency between fields.
Observed pattern. The most difficult errors are not technical rejections, but accepted files with substantively wrong data. Reconciliation against the case file avoids false security.
How to put it into practice
dictionary; extraction; transformation; validation; sample; legal review; hash; approval; submission; folio; immutable file; correction. Record any manual editing.
Layout as a controlled translation of the decision. The SITI structure begins with the applicable official version and its catalog, not with the file from the previous period. Each column is mapped to source data, transformation, validation and owner. Derived fields show the formula; conditionally mandatory fields include the rule that triggers their completion. Manual sheets are reduced and reconciled with the system.
The technical test uses valid records, missing data, disallowed character, deadline date and obsolete catalog. Encoding, length, totals, names and portal response are reviewed. Then a substantive control compares a sample against the case file, transaction and narrative to ensure that technical acceptance does not hide a content error. Corrections preserve the rejected file, message, cause and new version; the evidence is never overwritten. The transmission package includes the current layout, mapping, frozen base, validations, approval, hash, file, acknowledgment and final reconciliation. A regulatory change opens regression tests before the next due date and updates the procedure and the system.
Closing criterion. The frozen base receives an identifier and access control to prevent changes between approval and transmission. If it must be corrected, a new version is generated and the difference is approved again. The subsequent reconciliation compares expected, sent and accepted records, not just the monetary total.
Before closing, another user reproduces the totals through an independent query of the frozen base.
Legal basis
Narratives on profile, PEP and impersonation
Use facts in chronological order and internally cite the evidence. If there is an explanation from the client, include and assess it; do not omit it merely because it does not change the conclusion.
Observed pattern. The "what could not be verified" section improves transparency and helps design follow-up.
How to put it into practice
summary; profile; event; indicator; due diligence; explanation; corroboration; limitation; measure; decision. Consistency review with structured fields.
Accounts that distinguish identity, profile and signal. A PEP narrative explains the confirmed position or relationship, exposure and transaction; an impersonation one separates the real client from whoever used the data; a profile one shows the expected behavior and the concrete deviation. Mixing labels produces a confusing account and may attribute acts to the wrong person.
The drafter first prepares a chronology with sources. For impersonation it records channel, authentication, device, contact, claim and measures without disclosing unnecessary controls. For PEP it verifies match and date. For profile it compares amounts, frequency, counterparties and purpose. Each assertion is linked to evidence and speculation about intent is avoided. An independent reviewer confirms that the grammatical subject is always clear and that structured fields, case file and amounts match. The file preserves versions and the CO's decision. If data is missing, the narrative states the limitation factually instead of filling it by inference. The result must allow one to understand what happened, why it was analyzed and what support was available at the cutoff.
Closing criterion. Keep a glossary of terms that may imply judgment—"unusual," "simulated," "impersonated"—and require the fact that supports them. The reviewer replaces adjectives with observable actions where possible. This way the narrative retains precision even when the information is partial or contradictory.
The approved version also preserves the sources that made it possible to resolve any homonymy or doubtful attribution.
Legal basis
Critical fields in ROI and LPB
Establish consistency rules: report date later than the knowledge; amount equal to the base; valid currency; narrative compatible with type. Sample the master data.
Observed pattern. A table of "high-impact fields" concentrates the double review and reduces effort on low-risk elements.
How to put it into practice
classify critical/medium/low; source; transformation; validation; reviewer; exception; evidence. Block submission on a critical error and document an authorized override.
Fields that change the nature of the report. Identity, detection date, type of transaction, amount, currency, participants' role, product, location and legal basis must be treated as control elements, not administrative data. An error in any of them may alter the deadline, catalog or interpretation. The quality matrix assigns an authoritative source and validation per field.
For ROI and LPB, select a sample and reconstruct each value from the case file and transaction. Matches with lists are corroborated with identifiers; the role distinguishes client, beneficiary, recipient and third party. The date is not taken automatically from the alert creation if the trigger was another. The system blocks invalid catalogs, but the legal review checks consistency between type and facts. Before transmitting, totals and narrative are reconciled; afterward the exact file and acknowledgment are preserved. Errors are analyzed by cause—source data, transformation, capture or criterion—and the affected population is corrected. A quality dashboard shows rejections and substantive modifications per field, helping to direct remediation.
Closing criterion. Sensitive fields undergo a risk-based double review; not all need the same intensity. A rule may focus on dates, identity and type, while automatic validations cover format. The combination reduces material errors without turning the closing into a full re-capture by another person.
Every material correction requires reviewing whether other records were built with the same defective source.
Legal basis
Audit-ready control of reports
How to put it into practice
Preserve the exact file sent and the catalogs, not just the acknowledgment. Apply version control and retention. A subsequent correction is recorded without overwriting the original.
Observed pattern. The "deadline calculated by" field allows reviewing whether the deadline was counted from the correct event.
Tool: case_id; alert; knowledge; circumstance; deadline; analyst; decision; approver; file/hash; submission; folio; measure; closing; access. Run a monthly reconciliation between cases and SITI.
A case file that withstands a reconstruction. An audit-ready control preserves the original alert, source data, queries, profile, analysis, decision, approval, transmitted file, acknowledgment and follow-up. Each element carries date and version. The index allows moving from the folio to the narrative and back to the transaction without depending on the analyst who handled the case.
The independent test takes approved reports, dismissals and one correction. The auditor recalculates the deadline, verifies identity, traces amounts and confirms that the accepted file is the same one reviewed by the CO. It also reviews access and layout changes to rule out unauthorized substitutions. Personal data is kept in a restricted repository; extracts for internal bodies are minimized without breaking traceability. If a finding arises, the population and cause are determined, not just the visible case, and a new sample is run after correcting. Metrics include incomplete case files, differences between narrative and base, unreconciled folios and out-of-deadline decisions. That set demonstrates operation of the control, not merely the existence of acknowledgments.
Closing criterion. Define retention times and an export procedure that preserves context when the system changes. A screen PDF may lose catalogs, versions and relationships. The portability test reconstructs a closed case from the exported file and flags any dependency on the provider.
The annual sample includes at least one migrated case file to verify that its context remains available.
Legal basis
Subsequent LPB: when the 24 hours do not run and when to analyze an ROI
Do not turn this conclusion into a universal rule. Facts, provisions and the entity's involvement change. Document the alternative, legal basis and deadline.
Observed pattern. Searching for subsequent activity in all systems—not just the portfolio—avoids omitting a rejected instruction or reversed payment.
How to put it into practice
freeze chronology; consult list; confirm identity; search for transactions/attempts; review balances; analyze unusualness; decide; approve; report if applicable; monitor. Preserve negative evidence.
Chronology for a subsequent inclusion in the LPB. When the person appears on the list after a transaction, the analysis does not presume that a 24-hour circumstance existed on the original date. The current rule, the moment of publication or knowledge, the identity and any current relationship are verified. In parallel, the question is asked whether the transaction, seen with the new information, should be evaluated as an ROI under its own criteria.
Build a timeline with transaction, initial review, inclusion on the list, subsequent detection and decision. The system may run retrospective searches, but it must preserve original dates and not create a nonexistent "attempt." The CO documents separately the conclusion on the expedited route and the assessment of unusualness, including legal basis and limitations. If there is a current relationship, the measures applicable to the present state are activated. The file gathers the official publication, match, movements, profile, queries, decisions and files. A regression test confirms that future list updates generate cases with full traceability. The narrative, if applicable, explains the supervening datum without rewriting the operational history.
Closing criterion. The retrospective search must have a documented scope: period, products, fields and quality of identifiers. If there are potential matches, they are resolved individually. The closing reports the reviewed population and limitations, avoiding asserting that "there were no more cases" when certain systems did not contain sufficient data.
Legal basis
EOPERATIVA vs. ordinary ROI
Keep a catalog that translates internal names into obligations. For EOPERATIVA vs. ordinary ROI, the test is limited to its own data, decision and supporting documents. The file preserves the concrete route, form and folio. For EOPERATIVA vs. ordinary ROI, the test is limited to its own data, decision and supporting documents.
Observed pattern. Teams reduce errors when the system menu shows both the internal label and the legal name and deadline.
How to put it into practice
internal name; legal type; legal basis; trigger; deadline; fields; approver; evidence; portal. Review after layout or provider changes. For EOPERATIVA vs. ordinary ROI, the test is limited to its own data, decision and supporting documents.
Choice between EOPERATIVA and ordinary ROI. The label of the case does not decide the channel. The analyst identifies the nature of the event, type of transaction, subject, timing and current provision or instructions, and compares each requirement with the facts. EOPERATIVA may respond to a specific category; ordinary ROI requires the corresponding analysis of unusualness. The decision matrix preserves the discarded alternative and the legal reason.
Test two nearly identical scenarios that change only the trigger. The result must vary in an explainable way in type, fields, deadline and narrative. If the system automatically proposes a route, the CO confirms that the logic is up to date and may correct it with a trail. Structured data is reconciled with the history; generic text is not reused between types. The folder contains the regulatory query, chronology, case file, analysis, approval, layout, file and acknowledgment. After submission, the technical response is reviewed and similar cases are monitored to detect inconsistent classification. The objective is to sustain why the report was chosen, not to demonstrate that any submission within the deadline was sufficient.
Legal basis
CNBV, SOFOM forms and provisions. For EOPERATIVA vs. ordinary ROI, the test is limited to its own data, decision and supporting documents.
For EOPERATIVA vs. ordinary ROI, the test is limited to its own data, decision and supporting documents.
EOPERATIVA narrative with subsequent LPB
How to put it into practice
Draft in institutional third person, with consistent dates and without adjectives. Describe limits: information not available or not verified. The conclusion cites the applicable circumstance and the decision, not an accusation.
Observed pattern. A "blind" review by another analyst detects gaps in causation and phrases that confuse subsequent inclusion with a prior condition.
Tool: five blocks—facts, chronology, verification, analysis, measure—and a consistency checklist against the layout. The text is not reused as a template without adapting it.
Narrative of the event with subsequent data. In EOPERATIVA, a subsequent inclusion in the LPB must be described with exact dates and clear roles. The account identifies the original transaction, the third party, when the new information arose, how the match was confirmed and what the SOFOM did. It must not suggest that the entity knew the listing beforehand or invent a subsequent transaction to fit the format.
The drafting is prepared from a table of facts and sources. Each amount and date is reconciled with the file; the subject's name is distinguished from the client and the recipient. The reason for using EOPERATIVA is explained according to the current instructions, while any ROI analysis remains in its separate case file. A reviewer looks for assertions of intent, causation or identity that are not proven and corrects them. The package preserves the list query, match result, transaction, chronology, decision, approved version, transmission and folio. If the case reveals a monitoring gap, a technological remediation is opened independently of the report. This way the narrative reports the real event without distorting the temporal sequence.
Closing criterion. Before sending, read the narrative together with the date and type in the header as an authority without access to the case file would. If a different sequence appears to exist, rewrite the explanation or correct the structured datum. External clarity works as the final consistency test of the file.
Legal basis
Next step
SVA.LAW can review chronologies, decisions and narratives, and design a secure and auditable ledger.
General information; each report requires its own legal and factual analysis.