Avisos LFPIORPI y XML en SPPLD: calendario, formatos y control de calidad

¿Un Aviso LFPIORPI es lo mismo que un reporte de operación inusual?

El aviso ordinario se detona por actividad y monto o acumulación. El aviso de 24 horas parte de sospecha o hechos e indicios. El informe en ceros comunica que no hubo operaciones reportables conforme a la regla aplicable. Cada uno necesita una decisión documentada.

La taxonomía interna debe evitar términos ambiguos como “ROS” para todo. Conviene usar el nombre legal, plataforma, fundamento y dueño del proceso. Cuando un grupo tiene entidad financiera y Actividad Vulnerable, puede haber dos reportes sobre hechos relacionados, pero no se sustituyen entre sí.

El control maestro registra régimen, operación, fecha de conocimiento, vencimiento, presentación y acuse. Así se evita pensar que un envío en SITI satisfizo una obligación en SPPLD.

Cómo llevarlo a operación

Para un hecho compartido, abra expedientes relacionados pero separados. Cada sujeto decide conforme a su normativa, protege la confidencialidad y conserva su propia evidencia. El control debe permitir que los equipos colaboren sin copiar conclusiones ni datos personales innecesarios. Pruebe el calendario con tres escenarios: operación que cruza umbral, sospecha sin operación celebrada y mes sin operaciones reportables. Si los tres terminan en el mismo flujo o plazo, el diseño necesita corregirse.

Base legal

artículos 18, fracción VI, 23 y 24 de la LFPIORPI y Portal SPPLD.

¿Por qué DIN e INM no son intercambiables?

El expediente debe separar terreno, desarrollo, comercialización, promesa, compraventa, cesión y recepción de recursos. La misma empresa puede tener más de un rol. La fecha y el monto relevantes también pueden diferir según el acto.

Antes de generar XML se prepara una ficha de clasificación con: fracción del artículo 17, rol del sujeto obligado, contrato, inmueble, cliente, forma de pago y evento reportable. Esa ficha justifica por qué se empleó DIN o INM.

Los catálogos del portal son parte del control. Un código técnicamente aceptado puede describir mal la operación. Por ello legal valida clasificación y datos valida estructura.

Cómo llevarlo a operación

Use casos de prueba que incluyan una misma empresa con dos roles y un pago vinculado a varias etapas. Legal aprueba la clasificación; datos comprueba que el campo proviene de la fuente correcta; cumplimiento verifica umbral y presentación. Conserve versión del anexo, instructivo y catálogo utilizados, porque un cambio posterior no debe reescribir la explicación histórica. Si existe duda entre formatos, no resuelva probando cuál acepta el portal: la aceptación técnica no valida la calificación jurídica.

Base legal

actividades inmobiliarias del artículo 17 de la LFPIORPI e instructivos oficiales del SPPLD.

¿Qué errores de fechas, RFC, CURP y catálogos provocan rechazos?

El control debe validar estructura y semántica. La estructura revisa XSD, longitudes, tipo y obligatoriedad. La semántica compara datos con expediente, contrato, comprobante y operación. No debe “corregirse” un identificador para que pase el portal sin regresar a la fuente.

Las tablas de catálogos se versionan con fecha de descarga. Si el portal cambia una clave, el sistema preserva cuál se utilizó en cada aviso. Las correcciones manuales quedan en bitácora con solicitante y aprobador.

Un archivo de excepciones permite atender homonimias, extranjeros sin CURP o figuras jurídicas especiales sin llenar campos con datos ficticios.

Cómo llevarlo a operación

Implemente reglas en tres niveles. El primero verifica tipo, longitud y formato; el segundo cruza campos relacionados —persona moral frente a RFC, país frente a entidad, moneda frente a importe—; el tercero compara con el documento fuente. En presentaciones anonimizadas, una fecha válida pasó XSD pero correspondía a la captura en ERP y no al acto reportable. El portal no podía detectar ese error; sólo la conciliación jurídica lo reveló.

Cada corrección manual debe registrar valor original, valor nuevo, fuente, solicitante y aprobador. Mantenga catálogos con hash o versión y fecha de vigencia. Pruebe caracteres acentuados, nombres extranjeros, ausencia legítima de CURP, códigos postales y fechas límite. Para excepciones, use un flujo aprobado que no invente datos: documente por qué el campo no existe y cómo ordena capturarlo el instructivo vigente. Después del envío, analice rechazos por causa y sistema de origen; corregir únicamente el XML perpetúa el defecto en el siguiente periodo.

Base legal

recomendaciones técnicas SPPLD e instructivos y esquemas oficiales.

¿Cómo detectar operaciones inmobiliarias reportables?

El proceso comienza con el inventario de contratos y no con el XML. Para cada registro se identifica el rol de la empresa, tipo de acto, etapa y pagos. Se normaliza cliente y desarrollo; después se aplican umbral y acumulación.

Las bases inmobiliarias suelen tener datos dispersos entre ventas, tesorería y jurídico. La reconciliación debe detectar contratos sin pago, pagos sin contrato, clientes duplicados, cambios de titular y cesiones. Cada diferencia se resuelve antes del envío.

El tablero distingue “potencialmente reportable”, “validación legal”, “listo”, “presentado” y “corregido”. Un filtro binario no captura la investigación necesaria.

Cómo llevarlo a operación

Construya un ledger por movimiento con identificadores independientes de cliente, contrato, unidad e inmueble. Concilie al menos tres fuentes: contratos de jurídico, cobros de tesorería y titularidad de ventas. En datos anonimizados, los depósitos sin referencia se aplicaban días después; si el cálculo usaba la fecha de aplicación, podía mover operaciones entre periodos. La política debe definir el evento legal y conservar tanto fecha bancaria como fecha de imputación.

Ejecute controles de integridad: contrato sin cobro, cobro sin contrato, unidad duplicada, cesión sin actualización de cliente, devolución no vinculada y pago de tercero. Cada excepción se resuelve antes del estado “listo”. La ficha de revisión incluye fracción, formato, UMA, operaciones acumuladas, BC y explicación del medio de pago. Muestree también operaciones descartadas, pues un tablero sólo de positivos no revela fallos de cobertura. La trazabilidad debe permitir ir del acuse al inmueble y regresar de cualquier pago a la decisión de reporte.

Base legal

artículo 17 de la LFPIORPI vigente y formatos SPPLD.

¿Qué UMA debe utilizarse y por qué importa la fecha?

La base debe guardar multiplicador, UMA diaria, equivalente en pesos, fecha y resultado. Esto evita que un cambio anual altere históricos. En contratos con pagos sucesivos, la política define qué evento se evalúa y cómo se acumula.

No conviene redondear antes de terminar el cálculo. Se preservan decimales y se documenta la regla de comparación. Las cifras publicadas en una guía son referencia; el sistema obtiene el valor oficial vigente y lo somete a control anual.

La fecha tampoco debe inferirse siempre de la carga al ERP. Contrato, factura, pago y acto jurídico pueden ocurrir en momentos distintos. Legal determina el evento; datos conserva los campos.

Cómo llevarlo a operación

Administre la UMA como tabla con vigencia desde/hasta y doble aprobación, no como una constante en el código. El cálculo debe seleccionar el valor por fecha del evento, conservar decimales y mostrar la fórmula. En motores anonimizados, actualizar el parámetro anual sobrescribió históricos y convirtió operaciones de enero en falsos positivos. Un registro de versión y una prueba de regresión en el cambio del 31 de enero al 1 de febrero evitan esa alteración.

Prepare casos exactamente debajo, igual y encima del umbral, además de acumulación que quede exactamente igual y otra que lo supere. No confunda la comparación individual formulada como “igual o superior” con la regla de acumulación “supere”. Si la operación está en moneda extranjera, documente también el tipo de cambio requerido por el régimen aplicable y su fuente. El reporte de cálculo debe permitir que otra persona reproduzca el resultado sin acceder al código fuente.

Base legal

UMA 2026 publicada por INEGI y umbrales del artículo 17 de la LFPIORPI.

¿Cómo se distinguen aviso ordinario, informe en ceros y aviso de 24 horas?

El calendario debe manejar fechas de naturaleza distinta. Para ordinarios, operación y periodo. Para 24 horas, momento documentado de conocimiento o generación de sospecha. Para ceros, cierre y validación de que no hubo operaciones.

Un aviso de 24 horas no debe generarse sólo porque un cliente es de alto riesgo. Se documentan hechos, indicios y análisis. Tampoco se retrasa para esperar el cierre mensual.

El procedimiento debe proteger la confidencialidad del análisis y limitar accesos. La bitácora registra quién escaló, información considerada y decisión, sin divulgarla al cliente.

Cómo llevarlo a operación

Configure tres colas. La mensual recibe operaciones clasificadas y conciliadas; la de ceros exige que el dueño de datos certifique cobertura antes de declarar ausencia; la urgente registra instante de conocimiento, hechos y escalamiento. En prácticas anonimizadas, la alerta urgente quedó en una bandeja diseñada para el cierre mensual porque ambas se llamaban “aviso”. Nombrar la obligación y mostrar un contador visible reduce el riesgo de plazo.

No use riesgo alto como sustituto de indicios ni espere certeza penal. El analista documenta hechos, fuentes y razonamiento, y el aprobador decide bajo el estándar aplicable. Limite accesos y comunicaciones para no alertar al cliente. Para el informe en ceros, reconcilie población, fuentes y excepciones; “el sistema no generó alertas” no es evidencia suficiente si faltó una interfaz. Conserve presentación y acuse, y vincule el ordinario con las operaciones individuales que lo sustentan.

La bitácora urgente debe registrar zona horaria y momento exacto del conocimiento para que el cómputo de 24 horas pueda reproducirse.

Base legal

artículos 18, fracción VI, y 23 de la LFPIORPI, más obligaciones SPPLD.

¿Por qué desarrollo inmobiliario y compraventa se controlan por separado?

El desarrollador no debe asumir que el notario presentará todo aviso relevante. El fedatario cumple sus obligaciones respecto de sus actos; la empresa conserva las propias. Tampoco debe duplicarse automáticamente un aviso sin revisar qué actividad y sujeto se reportan.

La matriz por proyecto identifica vehículo propietario, desarrollador, comercializador, fiduciario y fedatario. Asigna actividad, evidencia y responsable. Así se puede explicar por qué un mismo pago aparece en distintos controles sin confundir duplicación con obligaciones concurrentes.

Los contratos deben reflejar con claridad quién recibe recursos y para qué. La base regulatoria no puede compensar un flujo contractual opaco.

Cómo llevarlo a operación

Cree una matriz RACI por proyecto: vehículo propietario, desarrollador, comercializador, fiduciario, comprador y fedatario. Para cada flujo indique contrato, cuenta receptora, propósito, actividad potencial, documento fuente y responsable de analizar. En proyectos anonimizados, el comercializador recibió depósitos en una cuenta concentradora y los transfirió al vehículo; ambos registros parecían ventas independientes hasta relacionarlos mediante un folio. La arquitectura debe conservar el movimiento sin contarlo dos veces como acto distinto.

Antes de abrir ventas, pruebe anticipo, cesión, cancelación, devolución, escrituración y pago por tercero. Verifique qué equipo actualiza titularidad y cómo se comunica el cambio a cumplimiento. No base el control sólo en la escritura: la recepción de recursos puede ocurrir antes. Al mismo tiempo, no presuponga que cada anticipo es avisable sin aplicar la fracción, umbral y acumulación correctos. La conclusión por flujo evita tanto omisiones como duplicaciones defensivas que degradan la calidad de los avisos.

Base legal

supuestos inmobiliarios del artículo 17 de la LFPIORPI e instructivos SPPLD.

¿Por qué agrupar operaciones puede destruir la trazabilidad?

La arquitectura correcta mantiene un ledger inmutable de movimientos y una vista calculada de acumulados. Si se corrige un movimiento, se registra reverso o versión; no se reemplaza silenciosamente. El aviso conserva referencia a las filas que lo originaron.

Agrupar por cliente exige un identificador confiable. Nombre o RFC capturado con variaciones puede dividir o unir indebidamente. La deduplicación se revisa antes de calcular.

Para auditoría se debe poder responder: qué operaciones componen este monto, por qué pertenecen al mismo cliente, qué UMA se usó y qué archivo se envió.

Cómo llevarlo a operación

Asigne a cada movimiento un ID estable y al aviso un ID de paquete. Una tabla puente relaciona ambos y guarda la versión del cálculo. En datos anonimizados, un total mensual se repartía después entre clientes mediante una hoja manual; al modificarse una fila, ya no coincidía con el XML aceptado. Congelar el paquete enviado, su hash y las filas componentes resolvió la reconstrucción sin impedir ajustes futuros.

La deduplicación necesita controles de identidad: RFC cuando exista, identificadores internos, fecha de nacimiento o constitución y revisión de coincidencias. No agrupe sólo por nombre ni divida por sucursal. Pruebe reversos, pagos parciales y cambios de titular. Para cada aviso, produzca un reporte reproducible con parámetros, operaciones, exclusiones y aprobador. Al corregir, conserve el cálculo anterior y muestre la diferencia. La trazabilidad protege tanto frente a omisión como frente a sobre-reporte causado por sumar dos veces el mismo flujo.

Una conciliación final debe demostrar que ninguna fila componente quedó vinculada simultáneamente a dos paquetes incompatibles.

Base legal

deber de conservar y reconstruir operaciones del artículo 18 de la LFPIORPI vigente.

¿Cuándo un error exige aviso modificatorio?

La política clasifica errores materiales y formales. Cliente equivocado, monto, Beneficiario Controlador o tipo de operación afectan el contenido. Un carácter o catálogo puede ser formal, pero no se minimiza sin análisis.

El expediente de corrección contiene aviso original, acuse, hallazgo, fuente correcta, aprobación, archivo nuevo y acuse posterior. Nunca se elimina la versión equivocada.

Los cambios repetidos son señal de causa raíz: catálogo desactualizado, interfaz manual, falta de validación o datos maestros defectuosos. El cierre incluye remediación del proceso.

Cómo llevarlo a operación

Clasifique el incidente antes de actuar: rechazo sin recepción; aceptación con dato formal incorrecto; aceptación con dato material incorrecto; o duplicidad. Consulte el instructivo vigente y documente la ruta. En correcciones anonimizadas, reenviar un archivo aceptado como si fuera nuevo produjo duplicidad; el equipo había conservado el XML, pero no el estatus ni el folio del acuse. El control maestro debe impedir una segunda presentación sin elegir expresamente su naturaleza.

La revisión de materialidad considera cliente, monto, actividad, BC, fecha y efecto en acumulación. Aun un carácter puede importar si cambia identidad. Después de corregir, compare campos entre versiones y reconcilie ambos acuses. Abra causa raíz cuando el error pueda repetirse: interfaz, catálogo, dato maestro, capacitación o revisión. La acción no termina con “portal aceptó”; termina cuando el expediente y el sistema fuente reflejan el dato correcto sin destruir la historia.

El responsable también debe revisar si el dato incorrecto contaminó otros avisos del mismo lote o periodo; corregir sólo el caso descubierto puede dejar una población idéntica sin atender.

Base legal

artículo 24 de la LFPIORPI e instructivos oficiales SPPLD.

¿Qué control de calidad debe ejecutarse antes del envío?

Checklist de preenvío

• versión vigente de formato, catálogo y XSD;
• sujeto y actividad correctos;
• cliente, representante y Beneficiario Controlador consistentes;
• fecha, monto, moneda y forma de pago cotejados;
• acumulación reproducible;
• campos condicionales completos;
• caracteres y longitudes válidos;
• revisión de muestra contra documentos;
• archivo, hash y aprobador registrados;
• acuse descargado y relacionado.

La conciliación posterior verifica aceptados, rechazados, pendientes y modificatorios. Un archivo generado no equivale a un aviso presentado.

Cómo llevarlo a operación

Divida funciones: quien extrae datos no debería aprobar en solitario la clasificación y quien carga no debería cerrar el control sin conciliar. En lotes anonimizados, el archivo pasó XSD pero omitió una fuente completa porque el conteo se comparó contra la misma extracción defectuosa. La reconciliación necesita una población independiente: ledger o control de operaciones, no otra salida del generador.

Registre totales por actividad, periodo, clientes, operaciones e importe; explique diferencias con el periodo anterior. La muestra debe cubrir mayor monto, límite, acumulación, persona extranjera, corrección manual y operación descartada. Después de la carga, verifique respuesta del portal, acuse y correspondencia de hash. Si hay rechazo, inmovilice la versión y abra incidente; no edite el archivo sin pista. Este paquete permite demostrar no sólo que se presentó, sino que la población fue completa y los datos provenían de evidencia autorizada.

Incluya además una conciliación de usuarios y privilegios del periodo: identifica cargas o ajustes efectuados por cuentas inactivas, compartidas o sin facultad y obliga a revisar su impacto antes del cierre.

Base legal

recomendaciones técnicas SPPLD, formatos SPPLD y artículo 24 de la LFPIORPI.