Cómo integrar goAML con el cribado PBC/FT y la gestión de casos

Una alerta no es una comunicación. Entre ambas se encuentran la investigación, la evidencia, la evaluación de sospecha, una decisión autorizada de comunicar, la preparación del informe y una transferencia técnica específica para cada país. Una integración fiable con goAML mantiene conectadas esas etapas sin fingir que constituyen un mismo control.

La prueba práctica es sencilla: ¿puede su equipo rastrear una señal desde su detección, pasando por la investigación y la decisión, hasta la información entregada a la UIF, y conservar después el registro de la presentación sin reconstruir la historia entre sistemas desconectados?

Dónde encaja goAML en el modelo operativo de PBC

La UNODC describe goAML como una plataforma que ayuda a las unidades de inteligencia financiera (UIF) a recopilar, analizar y difundir información financiera relacionada con actividades sospechosas.¹ Su descripción del producto incluye un portal para sujetos obligados, funciones de validación e interoperabilidad con otros sistemas.²

Esto describe el contexto global del producto, no un proceso universal de comunicación. La UIF que opera cada implementación nacional determina los tipos de informe, campos, métodos de presentación, permisos y procedimientos disponibles. Otras jurisdicciones emplean sistemas de comunicación distintos. El GAFI establece estándares internacionales que los países aplican mediante sus propios marcos jurídicos, administrativos y operativos.³

Por tanto, para un sujeto obligado goAML se encuentra después del modelo operativo general de cumplimiento de PBC:

Señal de negocio o de control → alerta → caso e investigación → evaluación de sospecha o de obligación de comunicar → decisión autorizada de comunicación → preparación del informe → transmisión específica de la UIF → respuesta o acuse de recibo de la UIF → conservación del registro

La secuencia puede comenzar con la monitorización de operaciones, el cribado de transacciones, la monitorización continua, una alerta de sanciones o PEP, una derivación interna u otra fuente. Ninguna de esas entradas acredita por sí sola una sospecha ni crea una obligación universal de comunicar.

No confunda detección, decisión y presentación

El requisito central de diseño consiste en asignar a cada estado de control su propio responsable, evidencia y resultado.

Esta separación evita que una alerta automatizada se convierta en una decisión automatizada de sospecha. También impide presentar un archivo técnicamente válido como un informe aprobado o aceptado. La decisión de comunicación y la evidencia del MLRO siguen siendo una responsabilidad gobernada por personas conforme al marco aplicable y al modelo de autoridad de la organización.

Empiece por un caso controlado, no por un formulario

Antes de diseñar correspondencias entre campos, haga reproducible la investigación previa. El caso debe conectar la alerta con el cliente, la cuenta, la operación y las partes relacionadas correctos; mostrar quién es responsable del trabajo; conservar notas, adjuntos y material fuente; y aportar una cronología de solicitudes, hallazgos, revisiones y decisiones.

Cuando la señal proceda del control de sanciones, complete el análisis de identidad y del régimen aplicable antes de tratar el caso como una posible comunicación de actividad sospechosa. La guía para documentar la investigación de una alerta de sanciones explica en detalle ese control previo.

Un registro útil para preparar la comunicación puede incluir:

• la señal original, los datos de origen y la referencia de la configuración o regla pertinente;
• el contexto de cliente, DDC, titularidad y relación disponible en ese momento;
• las personas, entidades, cuentas y operaciones pertinentes;
• evidencia favorable y contradictoria, adjuntos y casos anteriores relacionados;
• hallazgos del analista, cuestiones pendientes y solicitudes de información adicional;
• la evaluación de sospecha o de obligación de comunicar, la autoridad decisoria y el historial de aprobación; y
• referencias internas que permitan vincular el informe preparado y la posterior respuesta de la UIF con el caso.

Este es un modelo de control interno, no una lista universal de campos de goAML. El tipo de informe de destino y el paquete técnico de la UIF determinan qué datos deben transformarse o añadirse para la presentación.

Establezca una decisión autorizada antes de transferir el informe

Un investigador puede recomendar un escalado sin tener autoridad para presentar una comunicación externa. El sistema debe hacer visible esa diferencia.

Un control de aprobación identifica quién puede evaluar el caso, quién está autorizado a decidir la comunicación, qué evidencia estaba disponible, qué se decidió y si los cambios sustanciales exigen una nueva revisión. El software puede encauzar el trabajo, imponer estados internos y conservar el registro. No debe determinar autónomamente la sospecha jurídica, aprobar un informe en nombre del MLRO ni deducir que toda alerta debe comunicarse.

La preparación del informe solo comienza después de la decisión pertinente conforme a la política de la organización y la legislación aplicable. Si la información cambia durante la preparación, el flujo debe determinar si es necesario revisar la decisión o la aprobación, en lugar de modificar silenciosamente el fundamento de la presentación.

Traslade los datos del caso a la estructura de la UIF

La capa de correspondencia convierte la información controlada del caso en la estructura exigida por una UIF, un tipo de informe y una versión de implementación concretos. Puede abarcar personas y entidades, cuentas, operaciones, indicadores, narrativa, adjuntos e identificadores del sujeto obligado.

No parta de la premisa de que un único modelo XML de goAML funciona en todas partes. La FIAU de Malta publica material de implementación que incluye un XSD, ejemplos y un validador XML sin conexión.⁴ La MROS de Suiza publica especificaciones XML y manuales específicos del país.⁵ La UIF de Nueva Zelanda documenta la carga mediante XML para informes de operaciones prescritas (PTR), junto con otras opciones de presentación.⁶

Para cada destino, determine:

1. ¿Qué UIF y qué población de sujetos obligados están dentro del alcance?
2. ¿Qué tipos de informe están permitidos o son obligatorios para el caso de uso?
3. ¿Qué reglas se aplican a los campos, valores, adjuntos y narrativa?
4. ¿Qué esquema, paquete técnico o formulario del portal vigente rige la transferencia?
5. ¿Qué datos internos son la fuente autorizada y dónde debe añadir información específica de la presentación un usuario autorizado?
6. ¿Cómo se probarán, aprobarán y versionarán los cambios de correspondencia?

Estas preguntas importan incluso cuando la presentación final es manual. Un paquete de comunicación estructurado puede reducir la introducción repetida de datos y mantener la entrada en el portal alineada con el caso aprobado, pero un usuario autorizado debe seguir el proceso vigente de la UIF.

Elija el modelo de integración que realmente admite la UIF

«Integración con goAML» no significa necesariamente una API. Seleccione el modelo operativo solo después de verificar la interfaz, el tipo de informe y las reglas de acceso vigentes de la UIF.

Los ejemplos nacionales demuestran esta variación. Para los PTR de Nueva Zelanda, la UIF documenta formularios web, carga XML y presentación automatizada B2B, con pruebas obligatorias antes de autorizar el uso automatizado en producción.⁶ El FIC de Sudáfrica documenta la comunicación individual, por lotes y de sistema a sistema en determinados contextos.⁷ Estos ejemplos no acreditan que exista una API pública o para sujetos obligados en todas las implementaciones de goAML.

La misma arquitectura debe admitir destinos que no emplean goAML. El entorno de comunicación del SEPBLAC en España, por ejemplo, refuerza la necesidad de diseñar transferencias específicas para cada UIF en lugar de fijar un flujo goAML universal.

Valide la transferencia sin confundir las pruebas técnicas y jurídicas

La validación debe realizarse antes de que un informe aprobado abandone el flujo controlado. Según el método de la UIF, las comprobaciones pueden cubrir campos obligatorios, valores permitidos, referencias internas, reglas de adjuntos, estructura del archivo, el XSD aplicable y otras reglas de negocio publicadas.

Hay tres preguntas que deben mantenerse separadas:

1. ¿Es técnicamente válido el archivo o formulario? Cumple la estructura y las reglas de validación aplicables.
2. ¿Se ha recibido o aceptado para su tramitación? El destino ha generado la respuesta definida por ese flujo de la UIF.
3. ¿Ha sido jurídica y fácticamente adecuado el criterio de comunicación? El equipo autorizado ha aplicado la legislación y los hechos pertinentes.

Superar la primera prueba no responde a la tercera. La UIF de Nueva Zelanda declara expresamente en sus instrucciones de prueba de PTR que una revisión satisfactoria del archivo no confirma el cumplimiento normativo o legislativo.⁶ Del mismo modo, ninguna validación interna debe garantizar la aceptación de la UIF.

Incorpore rechazo, corrección y conciliación al flujo

La integración está incompleta si termina cuando se genera un archivo o un usuario pulsa enviar. El caso de origen necesita una forma controlada de registrar la respuesta del destino correspondiente al método elegido.

Los posibles estados internos incluyen preparado, aprobado para transferencia, transferido, a la espera de respuesta, recibido, rechazado, pendiente de corrección y conciliado. Son estados operativos útiles, no una afirmación de que todas las UIF expongan el mismo modelo de estados.

La FIAU de Malta ofrece un ejemplo específico: documenta la respuesta a las presentaciones y exige que los informes rechazados se corrijan de acuerdo con el mensaje de rechazo y vuelvan a presentarse.⁴ Un flujo interno que apoye ese proceso debe conservar el artefacto rechazado y el motivo, asignar la incidencia a un responsable, determinar si hace falta una nueva aprobación y vincular la presentación corregida con el caso original. El mecanismo preciso de corrección o comunicación complementaria debe proceder de las instrucciones vigentes de la UIF.

Ante una interrupción o una transferencia fallida, mantenga un responsable, un estado pendiente visible y un procedimiento alternativo documentado. No suponga que un fallo técnico amplía un plazo legal. Esa cuestión corresponde a la legislación y las orientaciones de la UIF aplicables.

Conserve una pista de auditoría de la comunicación

El registro debe permitir que un revisor autorizado reconstruya qué se sabía, qué se decidió, qué se preparó y qué se transfirió. Según la integración, conserve o vincule:

• la alerta de origen y la evidencia de la investigación;
• la evaluación de comunicación, la decisión, la persona que la aprobó y las marcas temporales;
• el artefacto aprobado o el registro de entrada en el portal;
• la versión de correspondencia, exportación o esquema utilizada, cuando corresponda;
• el usuario o sistema que presentó el informe y el intento de transmisión;
• la referencia, el acuse de recibo o el mensaje de rechazo de la UIF, cuando estén disponibles; y
• las correcciones, la información complementaria y las consultas posteriores.

Esta lista describe una pista de auditoría interna defendible, no un formato de registro ni un plazo de conservación de goAML exigidos globalmente. Conserve los registros conforme a la legislación y la política aplicables a la organización. Consulte Pista de auditoría y evidencia para conocer el modelo general de control de evidencia.

Gestione los cambios después de la puesta en marcha

Los formularios, esquemas, valores, permisos e instrucciones de una UIF pueden cambiar. Trátelos como dependencias gobernadas, no como detalles de implementación puntuales.

Un proceso práctico de gestión del cambio debe asignar la responsabilidad de supervisar las fuentes oficiales de la UIF, detectar nuevo material técnico, compararlo con la correspondencia vigente, ejecutar pruebas controladas, obtener la aprobación de negocio y cumplimiento, desplegar el cambio mediante el proceso habitual de publicación y conciliar las primeras transferencias en producción. Utilice información sintética o debidamente protegida y siga las reglas del destino: Nueva Zelanda indica a los sujetos obligados que no utilicen datos reales identificables en su entorno de prueba, y Suiza también advierte contra el uso de datos reales de clientes en su sistema de demostración.⁶⁵

Los procedimientos alternativos también deben probarse. Una conexión técnicamente elegante no constituye un control operativo si el equipo desconoce quién es responsable de una presentación fallida o cómo llega la información aprobada a la UIF cuando la vía habitual no está disponible.

Qué cambia según el país y la UIF

Lista de comprobación práctica para integrar goAML

• Identifique la UIF, el sujeto obligado, la jurisdicción y los tipos de informe aplicables.
• Nombre a los responsables de investigación, evaluación de sospecha, aprobación del informe, preparación, transferencia y conciliación.
• Mantenga la alerta, la investigación y la decisión de comunicar como estados distintos del caso.
• Defina la evidencia que debe estar completa antes de comenzar a preparar el informe.
• Obtenga los formularios, el esquema, las reglas de validación, las instrucciones de interfaz y los requisitos de acceso vigentes de la UIF.
• Traslade los datos autorizados del caso al destino sin sobrescribir la evidencia original.
• Elija un tratamiento manual, por carga, por lotes, de sistema a sistema o híbrido según el soporte confirmado de la UIF.
• Pruebe la validación técnica y las reglas de negocio sin presentarlas como prueba de cumplimiento jurídico.
• Conserve una decisión humana autorizada y controle quién puede transmitir el informe.
• Defina cómo regresan al caso los acuses de recibo, rechazos, correcciones, interrupciones y presentaciones pendientes.
• Conserve los artefactos, decisiones, marcas temporales y respuestas de la UIF pertinentes conforme a las reglas de conservación aplicables.
• Asigne la responsabilidad sobre los cambios técnicos de la UIF, las pruebas de regresión y los procedimientos alternativos.

Preguntas frecuentes

¿Existe una API universal de goAML?

No debe suponerse que exista una API universal para sujetos obligados. La UNODC describe la interoperabilidad en el ámbito del producto, mientras que cada UIF ofrece métodos de presentación distintos. Algunas UIF documentan comunicaciones automatizadas o de sistema a sistema, como Nueva Zelanda para los PTR y Sudáfrica en determinados contextos. Confirme la interfaz, la autenticación, los tipos de informe y el proceso de aprobación con la UIF correspondiente.

¿Es igual el XML de goAML en todos los países?

No. Varias UIF utilizan XML, pero el esquema, los tipos de informe, los valores obligatorios y las reglas técnicas aplicables pueden ser específicos de cada implementación y tener distintas versiones. Utilice el paquete vigente publicado o aprobado por la UIF de destino.

¿Puede el software PBC decidir automáticamente si se debe comunicar?

El software puede detectar señales, reunir evidencia, encauzar la revisión y preparar información estructurada. No debe adoptar de forma autónoma la evaluación jurídica de sospecha ni la decisión autorizada de comunicar. Ambas dependen de los hechos, la legislación aplicable y la gobernanza de la organización.

¿Realiza goAML la monitorización de operaciones del sujeto obligado?

No lo trate como sustituto de los controles del sujeto obligado. La UNODC sitúa goAML en torno a la recopilación, el análisis y la difusión por parte de las UIF. Los sistemas de cribado o monitorización de operaciones pueden generar señales previas que después entren en un flujo controlado de comunicación.

¿Un XML válido garantiza la aceptación?

No. La validez del esquema, la recepción técnica y la adecuación jurídica sustantiva son cuestiones distintas. Un archivo puede superar la validación estructural y aun así requerir corrección o revisión adicional conforme a las reglas de la UIF.

¿Qué debe ocurrir cuando se rechaza un informe?

Siga el procedimiento de la UIF correspondiente. Internamente, conserve el mensaje y el artefacto rechazados, asigne la corrección, determine si el cambio requiere una nueva aprobación, valide el resultado corregido y vincule la transferencia posterior con el caso original. No presuponga un único proceso universal de corrección o nueva presentación.

Conecte los casos de PBC con el flujo de comunicación

Checklynx ayuda a mantener conectadas las señales de cribado y monitorización con casos controlados, evidencias, notas, adjuntos, decisiones y cronologías. Sus integraciones PBC/FT pueden facilitar el intercambio de datos y evidencias con los sistemas del cliente. La función de cumplimiento autorizada conserva la responsabilidad sobre la evaluación de la sospecha, la interpretación de las políticas, la aprobación del informe y su presentación ante la UIF.

El diseño de integración debe corresponderse con la interfaz de la UIF realmente disponible para la organización. Que implique preparar la entrada en un portal, una exportación estructurada u otra vía admitida debe confirmarse para cada implementación; no es una promesa universal del producto.