S.A.F.E.-OSMS Cuadro de Detección de Operaciones Fraccionadas

En la Red, mucho se habla de las obligaciones que deben cumplir los Sujetos en Materia de Prevención de Blanqueo de capitales/Prevención de Lavado de Dinero/Anti Money Laundering  y Financiamiento al Terrorismo (FT), se habla mucho de las topologías de lavado y temas afines, pero poco de casos prácticos o como se debe hacer paso a paso... Vaya, que el tema de Blanqueo de Capitales es relativamente nuevo en el contexto Internacional.
Existen temas que en los textos parecen fáciles de implementar, pero que en la práctica puede nublar la mente del más avispado, en este caso, el de Operaciones Fraccionadas.
Las Operaciones Fraccionadas (Una topología típica) incluye dos sujetos:

- El Núcleo de Riesgo.
- El usuario de la Institución.

Núcleo de Riesgo.

Se puede definir al Núcleo de Riesgo a un grupo de individuos que en su conjunto pueden significar un Riesgo Común.
Dichos sujetos pueden estar relacionados de alguna forma y cuya relación puede ser consanguínea, por afinidad y económica.

Entonces, lo primero que de debe definir y establecer es que en las políticas de Conoce a tu Cliente (KYC) se deben relacionar las personas a través de al menos dos características.

1. Relación Persona-Persona por Consanguinidad o Afinidad.
2. Relación Persona-Persona por Vínculo económico.

Una vez obtenido estas relaciones, el sistema puede generar un árbol de relaciones por personas a una profundidad deseada, como la siguiente imagen.

Explicando de forma breve.

La profundidad de  relación se refiere a los niveles de relación que existen entre el Sujeto Principal y el Sujeto Relacionado.

El Sujeto principal tiene una relaciona con el Sujeto B2.1.1.2 con una profundidad 5, pues el Sujeto Principal se relaciona con el Sujeto B2 que se relaciona a su vez con el Sujeto B2.1 con una relación al Sujeto B2.1.1 con relación con al Sujeto B2.1.1.2,

• Nivel 1.- Sujeto Principal - Sujeto B. Nivel 1.
• Nivel 2.- Sujeto Principal - Sujeto B - Sujeto B2.
• Nivel 3.- Sujeto Principal - Sujeto B - Sujeto B2. - Sujeto B2.1
• Nivel 4.- Sujeto Principal - Sujeto B - Sujeto B2. - Sujeto B2.1 - Sujeto B2.1.1.
• Nivel 5.- Sujeto Principal - Sujeto B - Sujeto B2. - Sujeto B2.1 - Sujeto B2.1.1. - Sujeto B2.1.1.2.

Para el caso de S.A.F.E. OSMS el nivel de profundidad es hasta 6 y se actualizan al cierre del día, se puede acceder al árbol de relaciones y muestra una imagen similar al siguiente:

 Ya que tenemos relacionados en X profundidad los Sujetos solo hay que monitorear las operaciones del núcleo de riesgo por Usuario, sacando primero el numero y monto promedio de operaciones, que el caso de S.A.F.E.-OSMS es con la consulta:

SELECT
    `personas_relaciones_recursivas`.`persona`     AS `persona`,
    `operaciones_recibos`.`idusuario`                    AS `usuario`,
       
    CEIL( COUNT(`operaciones_recibos`.`idoperaciones_recibos`) /
    (DATEDIFF( MAX(`operaciones_recibos`.`fecha_operacion`), MIN(`operaciones_recibos`.`fecha_operacion`))
     + 1)
     ) AS `operaciones`,
    CEIL(SUM(`operaciones_recibos`.`total_operacion`) /
    ( DATEDIFF( MAX(`operaciones_recibos`.`fecha_operacion`), MIN(`operaciones_recibos`.`fecha_operacion`)) + 1)
    ) AS `monto`
FROM
    `operaciones_recibos` `operaciones_recibos`
        INNER JOIN `personas_relaciones_recursivas`
        `personas_relaciones_recursivas`
        ON `operaciones_recibos`.`numero_socio` =
        `personas_relaciones_recursivas`.`persona`
WHERE
    (`operaciones_recibos`.`origen_aml` >0)        
    GROUP BY
        `personas_relaciones_recursivas`.`persona`,
        `operaciones_recibos`.`idusuario`




Explicando, esta consulta obtiene el promedio de Operaciones y Monto que opera cada usuario por cada Nucleo de Riesgo.

Esto nos servirá de Perfil Transaccional por Núcleo de Riesgo.

La segunda consulta:

SELECT
    `personas_relaciones_recursivas`.`persona`     AS `persona`,
    `operaciones_recibos`.`idusuario`                    AS `usuario`,
       
    COUNT(`operaciones_recibos`.`idoperaciones_recibos`) AS `operaciones`,
    SUM(`operaciones_recibos`.`total_operacion`) AS `monto`
FROM
    `operaciones_recibos` `operaciones_recibos`
        INNER JOIN `personas_relaciones_recursivas`
        `personas_relaciones_recursivas`
        ON `operaciones_recibos`.`numero_socio` =
        `personas_relaciones_recursivas`.`persona`
WHERE
    (`operaciones_recibos`.`origen_aml` >0)
    AND
    (`operaciones_recibos`.`fecha_operacion`  = CURDATE())
    GROUP BY
        `personas_relaciones_recursivas`.`persona`,
        `operaciones_recibos`.`idusuario`

Analizará las operaciones del día por Nucleo de Riesgo.

Si las operaciones del día son mayores al promedio de este usuario, se envía una alerta del Sistema.

Básicamente el Sistema debe monitorear las operaciones entre Relacionados y alertar cuando estas operaciones suban del promedio diario por X usuario.

Saludos,


Luis Balam
http://www.opecorebanking.com/

Read More...

SAFE-OSMS : Cuadro de Detección de Operaciones Inusuales.

1. La Persona/Cliente realiza alguna operación que el Cajero registra en el Sistema.
2. El Sistema Obtiene datos de la persona, por defecto, toda operacion con PEPE/Relaciones PEPs o Personas de Alto Riesgo/Lista Negra son consideradas Inusuales.
3. El Sistema al guardar el registro Suma el Monto operado con el Total acumulado en el Mes, Cuenta dichas operaciones comparándolo con el Número y Monto de recibos Emitidos por el Sistema mismo.
4. Consulta el Perfil Transaccional de la Persona/Cliente a el cual se efectúa la operación.
5. Compara : Operaciones Actuales (Numero y Monto) vs Perfil Transaccional.
6. En el Caso que el Número o Monto sea mayor al declarado como Máximo el genera genera una Alerta por tres medios : SMS, Push Notificacion y email al Oficial de Cumplimiento.
7. El Oficial de Cumplimiento analiza la alerta y estudia los medios para reforzar la información al respecto.
8. Si es Positivo o negativo se registran la razones de ello.
9. Al ser Positivo se genera un registro de Riesgo en el Sistema, para luego ser Reportado a la CNBV.
10. Si es Negativo se Descarta y se guarda en el Sistema.

 


http://www.opencorebanking.com/
 

Read More...

¿En que se diferencian las Operaciones Inusuales de las Operaciones Internas Preocupantes?

Las operaciones Inusuales y Operaciones Internas preocupantes son básicamente el mismo concepto, sin embargo, su diferencia más notable es el enfoque de riesgo, pues al ser un Cliente el riesgo proviene de una fuente externa y al ser de un integrante de la propia financiera (Como un Empleado), el riesgo se origina dentro de la misma; siendo a su vez más elevado.

Por esto, podemos simplificar que la Diferencia es el origen del riesgo: Las operaciones inusuales serán las operaciones provenientes de fuentes externas, y las Internas (Obviando el nombre) serán de operaciones y/o acciones provenientes DENTRO de la Financiera.

Por lo tanto, tratándose de Sujetos de estudio de Operaciones, en las Operaciones Internas Preocupantes será el integrante de la Financiera, quienes pueden ser:

1. Empleados.
2. Directivos.
3. Consejeros.
4. Auditores Internos.
5. Toda Persona que pueda influenciar la operaciones de la Financiera.

Y en cuanto en la Operaciones Inusuales serán:

1. Clientes.
2. Socios.
3. Depositantes.
4. Transmisores.
5. Contratantes.

Así mismo, aún de ambos orígenes, se deben aplicar las reglas de KYC en ambos casos.


Luis Balam.
http://www.opencorebanking.com/

Read More...

SAFE-OSMS.- Módulo PLD.- Busqueda de personas. Algoritmos SQL

Para implementar el Módulo de AML/PLD y más específicamente la búsqueda de personas Sancionadas se utilizaron 3 Algortimos:

SOUNDEX.- Busca la similitud fonética entre dos palabras.
SOUNDS LIKE.- Mismo que Soundex pero sin redundancia.
DoubleMetaphone.- Tiene la misma función que soundex solo que con un algortimo diferente.
Jaro Winkler.- Función de Comparación de cadenas similar a Levenstein.

Luis Balam.
http://www.opencorebanking.com/

Read More...

Prevención de Lavado de Dinero.- Matrices de Riesgo

La Seguridad Informática y La Prevención del Lavado de Dinero / Financiamiento al Terrorismo (Blanqueo de Capitales), son parte de la Administración de Riesgos.
Por lo tanto, es perfectamente válido aplicar el Proceso de Administración de Riesgo a estas doctrinas. Hablaremos de Sujeto como nuestros Clientes, Accionistas, Empleados, Socios, etc... todo aquel que tenga una relación operacional con a Empresa (Que le llamaremos Entidad).
Igual que el Manejo de Riesgo de Crédito, podemos crear Instrumentos similares a la Método de las 5C o Credit Scoring.

Entonces, podemos generar Matrices para detectar o determinar si una persona tiene o es sujeto de riesgo AML combinando una serie de elementos básicos y asignándole una valor de riesgo.

Aunque existe una variante de criterios respecto a Como determinar metódicamente un Sujeto de Riesgo, lo más consensuado es :

Solo que hay que indicar, que los factores a Nivel Producto, Canal y Geográficos son determinados por la Operatividad y Caracterśticas propias de Entidad y no del Sujeto. Así, la autoridad reguladora tal como la CNBV nos estudia como Sujetos propios y la misma metodología debemos aplicar a nuestros Sujetos, agregando algunos elementos extras de estudio, tal como lo ejemplifica la siguiente tabla.

Aunque es casi lo mismo, debemos obtener elementos suficientes para evaluar a nuestros sujetos y esto se hace con una buena políticas de KYC.

Solo queda determinar la calificación  de cada elemento con una serie de combinaciones.
Como por ejemplo:

¿Es extranjero?
¿Es Persona Políticamente expuesta?
¿Opera o Vive en una Zona Geográfica establecida por la UIF como riesgosa?
¿Su Actividad económica es marcada como Riesgosa según la UIF?.
¿Su transaccionalidad es Inusual?
¿Tiene Relaciones con Personas Políticamente expuestas?.


Lo anterior ha sido más ilustrativo, pues la matriz de riesgo y su complejidad será dispuesta según el sistema.
Solo, para que sirva de ejemplo.

Saludos.

Read More...

SAFE-OSMS.- Módulo PLD/FT.- Casos de estudio.

Operaciones por Encima de Perfil Transaccional

Sujeto de Estudio : 9999
Tipo de Persona : Física.
Datos del Perfil Transaccional : Ninguno no se tiene registrado.

Notas de la Operación

Tipo de Operación : Pagos de la cuota de defunción. Log del Sistema en Modo root :

OK Se agrego exitosamente el Recibo : 15 : del Documento 1
OK CHANG Se cambio el Numero de Recibo de 15 a 15
SUCESS 15 Se agrego Exitosamente la Operacion(902) por 1500 con Numero 250 
ERROR No se genero el Movimiento Contable por Tipo de Pago(efectivo) por un Monto de 1500
OK AML Normal 
WARN Operaciones acumuladas por 78000.00
ERROR No existe el perfil
OK Operacion Normal de 78000 no sobrepasan 1000000.0000
OK Operacion Normal de 78000 no sobrepasan 500000.0000
OK Operacion Normal de 78000 no sobrepasan 300000.0000
OK Operacion Normal de 78000 no sobrepasan 100000.0000
OK Operacion Omitida por ser Moneda MXN de USD
OK Operacion Omitida por ser Moneda MXN de USD
ERROR efectivo Monto excedido de 20000 tuvo operaciones por 78000.00
OK efectivo Numero normal de 20 hizo operaciones por 1
ERROR efectivo Monto excedido de 0 tuvo operaciones por 1300.00
ERROR efectivo Numero excedido de 0 tuvo operaciones por 1
WARN 101 Agregando Monto 10000.000 con Numero 10
WARN 201 Agregando Monto 50000.000 con Numero 5
WARN 301 Agregando Monto 50000.000 con Numero 5
WARN 401 Agregando Monto 50000.000 con Numero 5
WARN 101 Sumando Monto 10000.000 con Numero 10
WARN 201 Sumando Monto 50000.000 con Numero 5
WARN 301 Sumando Monto 50000.000 con Numero 5
WARN 401 Sumando Monto 50000.000 con Numero 5
OK Mensaje Enviado a patadejaguar@gmail.com con exito.
ERROR Error con las credenciales
ERROR Aviso al oficial 99 Agregado con Exito (8|1|1|2014-09-24)
OK Mensaje 24/SEP/2014-911-ERROR efectivo Monto excedido de 20000 tuvo operaciones por 78000.00
OK efectivo Numero normal de 20 hi enviado con exito

Resultado

Exitoso : El sistema manda un mensaje por email, push notification y sms al momento de detectar una operación por encima de su perfil transaccional, aún si este está ausente.

Fecha:Miercoles,24 DE SEPTIEMBRE DE 2014
Hora:17:10
Ciudad:Merida
C. Oficial de Cumplimento:ADMINISTRADOR DEL SISTEMA

Alerta de Posible Riesgo AML

==========================================
Numero de Persona Involucrada:SUJETO DE PRUEBAS PARA REPORTAR
Numero de Documento Involucrado:14
==========================================
Fecha de Generación:24/SEP/2014
Hora de Generación:1710

Nivel de Riesgo ponderado del Sistema: 51.000000%
Tipo de Riesgo:operaciones. depositos/pagos mayores a su perfil
Clasificación:911
Vínculo de Alerta en el Sistema:  http://localhost/frmpld/alertas.verificar.php?id=911100

Notas:

ERROR efectivo Monto excedido de 20000 tuvo operaciones por 78000.00 OK efectivo Numero normal de 20 hizo operaciones por 1 ERROR efectivo Monto excedido de 0 tuvo operaciones por 1300.00 ERROR efectivo Numero excedido de 0 tuvo operaciones por 1 WARN 101 Agregando Monto 10000.000 con Numero 10 WARN 201 Agregando Monto 50000.000 con Numero 5 WARN 301 Agregando Monto 50000.000 con Numero 5 WARN 401 Agregando Monto 50000.000 con Numero 5 WARN 101 Sumando Monto 10000.000 con Numero 10 WARN 201 Sumando Monto 50000.000 con Numero 5 WARN 301 Sumando Monto 50000.000 con Numero 5 WARN 401 Sumando Monto 50000.000 con Numero 5 
Este es un Aviso Automatizado por el Sistema de Alertas de SAFE-OSMS, como posible riesgo marcado, en ningún caso se considera como un riesgo definitivo por lo que se necesita de su intervención para verificarlo.


Sistema de Alertas.- SAFE-OSMS
Código de rastreo: 911100

 Se estarán monitoreando otros casos.

Read More...