11. Saltar a contenido

11. Reglas de automatizacion de procesos en legajos

Nota

A menos que usted sea un experto en trak.e, probablemente no necesite esta funcionalidad.

trak.e ofrece la posibilidad de evaluar reglas genéricas en base a los datos de un legajo, a sus alertas, a su documentación asociada y a sus historial de transacciones. El resultado de dicha regla sera impactado en un atributo del legajo a definición del cliente. Se permite agregar cualquier cantidad de reglas genericas, pero a lo sumo 50 pueden estar activas al mismo tiempo.

11.1 Eventos

Las reglas genéricas se configuran para ser ejecutadas ante distintos eventos de trak.e. Cada regla puede configurarse ante uno o mas eventos. Los posibles eventos que disparan una regla son:

  • Nuevo legajo.
  • Actualización de legajo.
  • Nueva alerta.
  • Actualización de alerta.
  • Nuevo documento.
  • Actualización de documento.
  • Borrado de documento.
  • Nueva transacción.

Cuando se trate de un evento de actualización, debe ademas especificarse que el cambio de que atributo es el que dispara la regla. Puede utilizarse cualquier atributo en el top-level de la entidad correspondiente.

Por ejemplo, si pretendemos que la regla se ejecute cuando un legajo cambia de riesgo, podemos configurar el siguiente trigger:

...
"triggers": [
  {
  "event": "dprofile",
  "operation": "update",
  "field": "risk"
  }
]
...

11.2 Implementación

Las reglas siguen el esquema visto para la matriz de riesgo y el calculo del perfil transaccional: reglas escritas en lenguaje Python.

11.2.1 Parámetros

Las variables disponibles son:

  • profile: Al evaluar la regla se pone en el contexto de ejecución la variable profile que contiene el legajo que se esta procesando actualmente. Todos los atributos detallados en la sección Legajos se encuentra disponible en este objeto.

  • alerts: Al evaluar la regla se pone en el contexto de ejecución la variable alerts que contiene el historial de alertas abiertas y cerradas del legajo que se esta procesando actualmente. La variable es una lista donde cada objeto representa una alerta. Todos los atributos detallados en la sección Alertas se encuentra disponible en este objeto.

  • documents: Al evaluar la regla se pone en el contexto de ejecución la variable documents que contiene los documentos asociados al legajo que se esta procesando actualmente. La variable es una lista donde cada objeto representa un documento. Todos los atributos detallados en la sección Documentación se encuentra disponible en este objeto.

  • hist_trxs: Si la matriz de riesgo incluye información sobre la transaccionalidad del legajo, se puede acceder al histórico de la transaccionalidad del legajo con este nombre. La variable es puesta en contexto de ejecución en formato de pandas.DataFrame, donde cada fila del DataFrame representa una transacción y las columnas del DataFrame son los atributos de las transacciones (utilizando guion bajo como separador en caso de ser atributos anidados). Es posible que el historial este vacío (sin filas ni columnas) si el cliente no registra transacciones.

  • transaction: Al evaluar la regla de pone en el contexto de ejecución la variable transaction que contiene la transacción asociadas al legajo que se está procesando actualmente.

11.2.2 Resultado de la regla

La regla debe definir una variable de nombre ASSESSMENT_VALUE cuyo valor sera luego impactado en el legajo en el atributo definido en profile_json_path. El profile_json_path debe ser un JSONPath al atributo del legajo donde se quiere impactar el valor. Si el atributo existe sera actualizado, si no existe, sera creado.

Como ejemplo básico, si la regla lleva configurado profile_json_path: $.metadata.age y la ejecución de la regla determina que ASSESSMENT_VALUE: 43 para cierto, se creará o actualizará en dicho legajo el valor del atributo age dentro la de información adicional.

No es necesario que el atributo a actualizar sea parte de la información adicional, también se puede actualizar campos predefinidos. Por ejemplo, una regla que escriba el campo state puede utilizarse para definir transiciones automáticas entre estados del legajo bajo las reglas de negocio que defina el cliente.

Nota

Algunos atributos del legajo no se pueden modificar automáticamente. Esto incluye: - identificador (id). - número de versión (version). - fecha de creación y modificación y usuario que creo/modifico. (created_at, modified_at, created_by, modified_by). - CUIT/CUIL (tax_payer_id). - número de referencia externa (external_ref). - cabinet donde se encuentra la documentación del legajo (documents). - fecha de ultimo chequeo en listas, calculo de riesgo y perfil transaccional (blacklists_checked_at, transactional_profile_amount, transactional_profile_calculated_at, risk, risk_calculated_at). - tipo de persona PF/PJ: (person_type).

Nota

Contexto: Además de los valores utilizados para interpretar la evaluación de la regla y que será eventualmente impactado en el legajo, se devuelve el contexto de la evaluación, particularmente aquellas variables públicas definidas. Esto permite guardar valores calculados durante la ejecución de la regla y que los mismos estén disponibles al momento de ver los resultados.

11.3 Testing de la regla

Trak.e permite testear la regla antes de guardarla con cualquier legajo de la base o con un legajo armado a necesidad para testear casos bordes y asegurarse de que la regla es correcta tanto sintáctica como semanticamente.

11.4 Nombre y descripción

La regla se guarda con un nombre, el cual debe ser único.

La regla permite adjuntar ademas una descripción en formato de texto enriquecido.

11.5 Ejemplo: Actualizar información en listas

La siguiente regla de automatización de procesos mantiene la información en listas del legajo consistente con el analisis que hagan los operadores de los casos del mismo. Mientras una alerta este en progreso, se mantiene abierto el hit pero sin confirmar. Al cerrar se decide: si el analista a confirmado el hit lo marca como confirmado en el legajo, y si no lo ha confirmada, descarta el hit completamente. Esto es solo un ejemplo - se puede adaptar a las necesidades de cada entidad.

blacklist_info = profile.blacklist_found 
if blacklist_info is None:
    blacklist_info = {}
for alert in alerts:
    incident_state = alert.state
    incident_type = alert.incident_type
    if "blacklist_hit" in incident_type:
        match_type = alert["info"]["match_type"]
        confirmed = alert["info"]["confirmed"]
        if incident_state == "open":
            blacklist_info[match_type] = {}
            blacklist_info[match_type]["hit"] = True
            blacklist_info[match_type]["confirmed"] = False
        elif incident_state in ("in_progress", ):
            blacklist_info[match_type] = {}
            blacklist_info[match_type]["hit"] = True
            blacklist_info[match_type]["confirmed"] = False
        elif incident_state in ("closed", "reported"):
            if confirmed:
                blacklist_info[match_type] = {}
                blacklist_info[match_type]["hit"] = True
                blacklist_info[match_type]["confirmed"] = True
            else:
                blacklist_info.pop(match_type, None)

k = None
v = None
blacklist_info = { k: v for k,v in blacklist_info.items() if v }

ASSESSMENT_VALUE = blacklist_info

La regla se configura con el profile_json_path en $.blacklist_found.

La regla se configura con los siguientes disparadores:

    ...
    "triggers": [
        {
            "event": "incident",
            "operation": "add",
            "field": null
        },
        {
            "event": "incident",
            "operation": "update",
            "field": "state"
        },
        {
            "event": "incident",
            "operation": "update",
            "field": "info"
        },
        {
            "event": "incident",
            "operation": "update",
            "field": "confirmed"
        }
    ],

Esto indica, cada vez que se agrega una nueva alerta, o cada vez que se acutaliza el estado, la información, o el campo "confirmado" de la misma.

11.6 API

Para más información técnica sobre cómo crear, buscar y modificar reglas genéricas de automatización de procesos en legajos, se encuentra disponible la documentación de la API.