El caso no es el fiddle
La base del ejercicio es un recorte de 2022. En el uso diario llegan ticks de forma continua. Diseñar sobre un snapshot estático lleva a cachear de más: una vista materializada sirve para un conjunto que casi no cambia.
Customer Success Analyst · Complif
Desde Complif me invitaron a resolver este desafío para mostrar mis habilidades, desde los datos hasta la comunicación.
¡Te cuento cómo lo hice!
El desafío
Arranco por qué tiene que funcionar en el uso cotidiano, para quién, y qué no se puede inventar. Miro el caso real, no el recorte del ejercicio: si los datos entran todo el tiempo, un índice alcanza y materializar sobra; si hay un contrato, lo leo entero —incluso los huecos—; si hay un flujo, busco dónde se traba y quién queda esperando. SQL, APIs, el pedido a TECH y los procesos salen de esa misma lógica.
Ejercicio 1 · SQL
El fiddle trae ticks estáticos de 2022. El caso real es cotidiano: entran cotizaciones MEP todo el tiempo. Por eso no materializo la serie: cada insert invalidaría el cache. El gráfico lee la vista mep_implicito, con índice y un SELECT paginado.
El caso no es el fiddle
La base del ejercicio es un recorte de 2022. En el uso diario llegan ticks de forma continua. Diseñar sobre un snapshot estático lleva a cachear de más: una vista materializada sirve para un conjunto que casi no cambia.
Índice, no materializar
En precios, índice por (datetime, moneda, id), ordenado por instante. Fecha y moneda son las claves de acceso; id desempata porque el par no es único. El motor busca el rango sin barrer la tabla ni pagar un REFRESH en cada carga.
Consulta
Pido datetime, venta y compra, filtro el rango en el WHERE y corto con LIMIT para paginar. Se puede en la query porque es SQL nativo, no un modelo de entidades tipo Hibernate.
Consulta
SELECT datetime, venta, compra FROM mep_implicito WHERE datetime >= '2022-01-25T00:00:00.000-03:00' AND datetime < '2022-01-26T00:00:00.000-03:00' ORDER BY datetime ASC LIMIT 5000;
Última venta
216,61 ARS
Última compra
217,12 ARS
Spread
0,507 ARS
Rango venta
215,6 – 218,5 ARS
Tipo de cambio MEP implícito
03:49:33 p. m.
Venta
216,61 ARS
Compra
217,12 ARS
Ejercicio 2 · APIs
Un Swagger no es el producto: es el contrato. El ejercicio pide dos flujos sobre Petstore y para qué usaría APIs en Complif. En cada paso miro el código de respuesta: si el contrato no lo declara, el flujo se corta igual.
01
Si quisiera darme de alta como usuario, y luego comprar un perro llamado Buho. ¿Cuál sería el flujo de ejecución de endpoints?
Alta de usuario
POST /user con un id. Reviso el código de respuesta antes de seguir.
Alta sin código de error
El Swagger solo declara default. Si falla, el contrato no dice con qué 4xx parar.
Mascotas available
GET /pet/findByStatus?status=available. Trae el listado completo.
Status inválido
400: el query no es available, pending o sold. No hay listado ni petId.
¿Hay un perro Buho?
El servidor no filtra por nombre ni tipo: lo hago yo en el cliente.
Buho no está
Sin match no hay petId. No puedo armar la orden.
Comprar a Buho
POST /store/order con el petId. El body no lleva usuario.
Orden inválida
400: el pedido no cumple el modelo Order. La compra no se registra.
Compra hecha
200 y el Order. No queda ligado al usuario que di de alta.
02
Ahora quiero que ese mismo perro se llame Mono, pero me olvidé mi usuario, ¿cómo puedo hacer?
Renombrar a Mono
POST /pet/{petId} con name=Mono. No hace falta el username.
Input inválido
405: el único error que documenta este endpoint. El nombre no cambia.
Ahora se llama Mono
El 200 no figura en el Swagger: el éxito tampoco está en el contrato.
Razonamiento
La API no asocia las compras a usuarios. Eso permite renombrar si olvidé el username, pero es una pérdida de información. Tampoco menciona credenciales: un riesgo. Y no filtra en el servidor: para buscar a Buho hay que traer todo el listado available y filtrar tipo y nombre en el cliente.
03
¿Para qué pensás que podríamos usar APIs en Complif?
Razonamiento
Una empresa como Complif sería prácticamente imposible sin APIs: exponen servicios bajo contrato, y en un SaaS con varios clientes y proveedores eso es clave. Sin ellas, habría que completar formularios con automatización web o scrapear; no escala. Con APIs, Complif puede conectar un formulario del home banking de Banco Boquita con un servicio propio.
Ejercicio 3 · Pedido a TECH
Armé el pedido como un ticket de Customer Success: el detalle que TECH necesita para desarrollarlo, sin redescubrir el contrato en el Network.
Problema
Para el monitoreo transaccional de Banco Boquita hace falta el histórico de dólar MEP valuado al cierre de cada día hábil. Hoy no hay tabla ni integración con el proveedor.
Objetivo
Extraer la valuación de cierre todos los días hábiles y persistirla. Re-correr un día no debería duplicar ni pisar mal un cierre ya validado.
Contexto
Proveedor: Ámbito. No hay docs oficiales del API: el contrato se descubre en el Network de la página de histórico al filtrar desde / hasta.
Pedido a TECH
TECH-03
AbiertoAsunto
De
Facundo Krens
Customer Success
Para
TECH
Cliente
Banco Boquita
[
[
"Fecha",
"Referencia"
],
[
"07/07/2026",
"1529,19"
],
[
"06/07/2026",
"1525,47"
],
[
"03/07/2026",
"1524,53"
],
[
"02/07/2026",
"1529,77"
],
[
"01/07/2026",
"1521,03"
]
]Ejercicio 4 · Procesos (I)
Cinco preguntas sobre el diagrama de Camunda. Abajo, el glosario del PDF para no perder el vocabulario.
Perfil transaccional
Límite operativo estimado. Si fondea más de lo previsto, hay riesgo de lavado. Sale de comprobantes de origen de fondos, ponderados por cliente.
NSE
Nivel socioeconómico: poder adquisitivo estimado, vía bureau.
Requerimiento
Mail al usuario para pedirle información.
OCR
Lee documentos y dispara acciones según el contenido.
01
¿Por qué pensás que se crea un caso y luego se busca información del NSE? ¿No convendría buscarlo antes de que se genere el caso?
Razonamiento
Pienso que se hace así porque el NSE viene de una entidad externa, lo cual muy probablemente implique costos por consulta, y además cierto tiempo pues se debe aprobar el acceso a dichos datos personales. No tiene sentido consultarlo si ya se encuentra dicha información vigente almacenada en la base de datos propia. La alerta se dispara cuando un usuario opera por encima de su perfil. Ahí se arma el caso, y el NSE es una consulta que se cuelga de ese expediente, no al revés. Crear el caso primero también permite ver si ya hay un NSE reciente de esa persona y reutilizarlo, en vez de volver a pagarlo. El caso es el lugar donde quedan asentadas la alerta, las consultas y, después de revisar, si se trata o no de lavado de dinero. Esto permite persistir un seguimiento documentado.
02
¿Creés que el proceso se pueda trabar por alguna razón?
Razonamiento
Sí, en varios puntos. Por ejemplo en la consulta al organismo encargado del NSE (si no responde o se cae), en la carga de documentación que tiene que hacer el usuario, en la aprobación del requerimiento, y en el análisis o revisión por parte del cliente B. Particularmente, el requerimiento al usuario final es el que considero que representa un riesgo mayor de trabar el flujo, por múltiples razones (la persona no revisa su casilla de mail, no cuenta con la documentación, cree que si lo ignora no va a pasar nada, etc). Distinto es que un servicio falle (el organismo del NSE, el OCR) a que una tarea humana no se tome nunca. El proceso junta varias partes, cada una con sus tiempos y responsabilidades. Si no hay un vencimiento o un recordatorio, queda trabado.
03
En el requerimiento enviado al cliente… ¿qué documentación le estás pidiendo?
Razonamiento
Por lo que entiendo, el requerimiento va al usuario (el consumer), no al banco. Entiendo que se le está pidiendo una declaración jurada sobre sus bienes, y comprobantes que permitan determinar el origen de sus fondos.
04
¿Por qué hay una clasificación de OCR? ¿Qué evaluarías en un documento para determinar si se aprueba o rechaza?
Razonamiento
La clasificación está porque el OCR no solo lee el archivo: tiene que decir de qué tipo es, y según eso se sigue un camino u otro. Si es un recibo, se puede extraer monto y fecha. Si no es un comprobante de origen de fondos, se rechaza y se vuelve a pedir. Para aprobar o rechazar miraría el tipo de documento, que el titular coincida con la persona del caso, la fecha de vigencia (un recibo de hace tres años no sirve para una operación actual), que el monto se pueda leer, que el archivo sea legible, y que lo que aporta coincida con lo pedido. También habría que revisar cuestiones de validez: firmas, entidad que lo emite, coherencia del contenido con el marco regulatorio, entre otros.
05
Si vos fueras analista de Compliance… ¿qué investigarías de un cliente que opera más de lo que tiene permitido?
Razonamiento
Investigaría primero hace cuánto viene operando de esta manera. No es lo mismo una transacción extraordinaria que la repetición de movimientos fuera de lo permitido, que ya pediría una indagación en el origen de los fondos. También las cuentas involucradas. Trazar las operaciones permite ver si son movimientos entre familiares (por ejemplo, un estudiante que recibe dinero de sus padres para estudios, alquiler y gastos del mes), o si la situación es más compleja: apuestas ilegales, estafas, lavado de dinero, entre otros. Miraría los montos. Gran parte de la economía argentina se mueve por el empleo informal. Muchas personas cobran fuera de recibo, y eso, si bien es irregular, no es lo mismo que una organización ilícita. Igualmente, que se trate de un caso de empleo informal no implica el cierre automático del caso: desde mi punto de vista, reduce la gravedad y urgencia con la cual se conlleva el proceso.
Ejercicio 5 · Procesos (II)
El PDF pide un flujo con condiciones de entrada y salida claras, a partir del video del Líder de Onboarding. Abajo está el modelo de Camunda: mismas formas (tareas, pasarelas, eventos) y el mismo lienzo. Arrastrá para recorrer el flujo.
Asesor comercial
Abre el caso, arma el formulario, dispara los requerimientos y calcula la matriz de riesgo. Si el cliente no sigue, cierra con un agradecimiento.
Representante cliente
Completa el formulario, acepta los términos y entrega la documentación societaria cuando el banco se la pide.
Legales
Riesgo bajo o medio va a analistas; si no, al líder. Revisan vigencia de estatutos, balances, constitución y poderes, y calculan el perfil transaccional.
Equipos de clientes
Si el perfil supera 20.000 UVAs, entra Institucionales. Si no, PYMEs. El equipo que corresponda aprueba o rechaza.
Data entry
Revisa el expediente y carga a mano en el CORE, el registro único de clientes. Si hay un error, vuelve al equipo comercial.
Entrada y salida
Entra con el contacto del asesor. Sale por rechazo (sin intención, sin T&C o sin aprobación) o por la carga en el CORE.
Banco Boquita · Persona Jurídica
Arrastrá el lienzo · rueda o botones para zoom.
Contacto