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 variableprofile
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 variablealerts
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 variabledocuments
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 variabletransaction
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.