Si aprobás pagos en segundos, también tenés que controlar en segundos. Yo resumiría este checklist así: antes de activar, tengo que validar identidad, correr sanciones/PEP/AML, fijar límites en ARS, mirar país y dejar logs completos con alertas y escalado.
En otras palabras: no alcanza con “tener reglas”. Yo necesito que estén definidas, configuradas y bajo monitoreo desde el alta del cliente hasta la revisión de una alerta. Si no, un pago de ARS 49.000,00 repetido varias veces, un salto de ARS 10.000,00 a ARS 200.000,00 en una hora, o una coincidencia parcial en listas puede pasar sin control.
Puntos que me llevo de entrada:
Comparación rápida
| Área | Qué tengo que definir | Qué dispara revisión |
|---|---|---|
| KYC | Identidad, CUIT/DNI, perfil, origen de fondos | Cambios de volumen, ticket, tráfico exterior, alertas AML/fraude |
| Sanciones y PEP | Listas, frecuencia de actualización, umbral de match | Coincidencia exacta o parcial |
| AML | Reglas de velocidad, monto, intentos, geolocalización | Picos fuera de patrón, smurfing, device/IP rara |
| Límites | Tope por operación, diario y mensual | 80%, 90%, rechazos repetidos, exceso de volumen |
| País | Permitido, revisión reforzada, bloqueado | Ruta restringida o cambio de corredor |
| Logs y alertas | Campos obligatorios, severidad, SLA, aprobador | Toda retención, bloqueo o reversa |
Con este mapa, ya sé qué revisar para operar pagos instantáneos sin dejar huecos en cumplimiento ni en soporte.
Flujo de Decisión para Pagos en Tiempo Real: KYC, Screening y AML
Antes de habilitar pagos en tiempo real, validá la identidad, el origen lícito de los fondos y el perfil de riesgo. Además, guardá la documentación por 5 años. Con esa base, el paso siguiente es dejar claro qué campo pide cada tipo de cliente.
Estos son los campos mínimos por tipo de cliente. Tienen que estar estandarizados en formato fijo - string, fecha DD/MM/AAAA y numérico - y ser iguales en checkout, CRM y back-office.
| Tipo de cliente | Campos de identidad obligatorios | Datos fiscales/comerciales |
|---|---|---|
| Consumidor final | Nombre completo, DNI (o CUIL/CDI si corresponde) | Domicilio completo y código postal |
| Responsable Inscripto | CUIT, razón social | Condición fiscal (IVA), validación ARCA |
| Monotributista | CUIT, nombre completo | Categoría vigente |
| Persona jurídica | CUIT, razón social, acta constitutiva e inscripción societaria | Domicilio fiscal y de sucursales, beneficiarios finales ≥20%, representantes legales |
Una vez identificado el cliente, toca cargar los campos que marcan su riesgo operativo.
Estos cuatro campos alimentan de forma directa el motor de decisión:
Con esos datos, clasificá el perfil en tres bandas:
Esa clasificación tiene que calcularse en forma automática y verse en el back-office. No es un dato decorativo: define los límites por defecto, la intensidad del monitoreo y si ciertos pagos pasan o no por aprobación manual.
Revisá el KYC con esta frecuencia según el nivel de riesgo: bajo, cada 2–3 años; medio, cada 1–2 años; alto, al menos una vez por año. Pero no alcanza con mirar el calendario. Hay eventos que obligan a revisar antes.
Si aparece un aumento abrupto del volumen en ARS por encima de lo declarado, un cambio en el ticket promedio, más tráfico transfronterizo, rechazos repetidos por riesgo o alertas de AML o fraude, hay que actuar. En cualquiera de esos casos, pausá los pagos en tiempo real y pedí documentación actualizada antes de devolver el acceso.
El acceso a datos sensibles de KYC se maneja con control por rol (RBAC). En la práctica, cada equipo ve solo lo que necesita:
Cada acceso o cambio tiene que quedar registrado con usuario, rol, fecha y hora (DD/MM/AAAA HH:MM), campos tocados y resultado.
Con el KYC completo, el filtro que sigue es el screening de sanciones, PEP y monitoreo AML antes de liberar fondos.
Con el KYC activo, el control que sigue es el screening de sanciones y el monitoreo AML sobre el cliente, los beneficiarios finales, la contraparte y otros terceros que importen. Este chequeo corre antes de aprobar, durante la evaluación y cada vez que se dispara una alerta. La revisión de PEP también tiene que ser continua y basada en riesgo, con debida diligencia reforzada - retención, bloqueo o escalado - en relaciones con mayor exposición.
Con la identidad ya validada, el paso siguiente es cruzar datos contra listas y activar monitoreo AML en tiempo real.
Consultá OFAC/SDN, ONU, UE, listas PEP y resoluciones o comunicaciones vigentes de UIF y BCRA.
Las listas públicas tienen que sincronizarse todos los días. Las resoluciones de UIF y BCRA, en cambio, deben cargarse apenas se publiquen. Si manejás mucho volumen, conviene usar sincronización automática varias veces por día, con registro de versión y hash de verificación para confirmar que la actualización quedó aplicada como corresponde.
El motor de coincidencia tiene que trabajar con fuzzy matching, usando un umbral de similitud configurable de 85–90% sobre el nombre legal completo. Antes de comparar, normalizá tildes y partículas comunes como “de” y “del”. Para bajar falsos positivos, sumá al menos un dato más - fecha de nacimiento, país de nacionalidad, CUIT/CUIL o domicilio - como condición de escalado.
Cada resultado debe quedar documentado con estos datos:
Ese registro deja el caso listo ante una eventual inspección de la UIF o del BCRA.
Después del screening, el motor tiene que mirar el comportamiento transaccional y definir si corresponde retención o bloqueo según el nivel de riesgo.
En pagos en tiempo real, el monitoreo AML no puede correr por lotes (batch). La decisión se toma en segundos. Para e-commerce en ARS, las reglas mínimas son estas:
Los umbrales no se fijan “a ojo”. Tienen que calibrarse con datos históricos del propio comercio y ajustarse por categoría de producto y por eventos de alta demanda - como Hot Sale - , donde la velocidad sube de forma natural.
Con ese puntaje sobre la mesa, la decisión puede automatizarse o pasar a revisión humana.
Asigná a cada transacción un puntaje de 0 a 100 según screening, riesgo KYC, monto, velocidad, dispositivo, geolocalización e historial. El ruteo queda así: 0–30 autoaprobar, 31–70 retener, 71–100 bloquear.
| Rango de puntaje | Decisión | Acción |
|---|---|---|
| 0–30 | Autoaprobación | Liberación inmediata; log básico del evento |
| 31–70 | Retener para revisión | Suspensión del pago; asignación a analista en ≤30 min durante horario hábil |
| 71–100 | Bloqueo automático | Retención definitiva; escalado a cumplimiento senior; evaluación de un eventual reporte a la UIF |
Por cada caso, registrá el ID del pago, el timestamp en formato DD/MM/AAAA HH:mm, el monto en ARS, el puntaje, los factores considerados y el responsable. También hace falta documentar los falsos positivos junto con el motivo del descarte.
Cuando el riesgo no está en el cliente sino en el corredor o en el país, pasan a pesar más los límites y las restricciones geográficas.
Cuando el flujo no da para bloquear, los límites operativos funcionan como una segunda barrera. Una operación que, vista sola, parece normal puede pasar a ser riesgosa por acumulación, repetición o por tocar una jurisdicción restringida.
El BCRA fija un piso regulatorio de 15.000 UVAs por día y por cuenta para transferencias inmediatas en pesos - unos $ 3.274.000,00 al 31/03/2023 - y de USD o EUR 12.500 diarios en moneda extranjera. Ese es el mínimo regulatorio. Después, cada entidad puede marcar topes propios más bajos según el perfil del cliente.
Conviene definir tres cosas desde el arranque: tope por operación, acumulado diario y acumulado mensual. Y no alcanza con un límite general. Hay que separar por KYC, antigüedad, fraude previo, método de pago, geografía y comportamiento.
| Segmento | Límite por operación | Límite diario / mensual |
|---|---|---|
| Nuevo / sin verificar | Hasta $ 50.000,00 | Conservador en ARS |
| Verificado bajo riesgo | Hasta $ 250.000,00 | Ajustado al comportamiento esperado |
| Alto riesgo / en revisión | Muy por debajo del estándar | Los más bajos del esquema |
También sirve marcar umbrales internos para reaccionar antes de llegar al techo:
Si el flujo cruza jurisdicciones o suma intermediarios, además del límite monetario hay que aplicar la regla de país.
La regla de país no se mira sola. Se evalúa junto con sanciones y PEP antes de liberar fondos. Un mismo cliente puede verse como de bajo riesgo en una compra local y, al mismo tiempo, necesitar controles más duros si la transacción incluye destino, beneficiario o jurisdicciones intermedias fuera de Argentina.
La forma más simple de ordenarlo es clasificar los países en tres grupos: permitido, revisión reforzada y bloqueado. Esa lista tiene que ser dinámica, y su actualización queda bajo responsabilidad de cumplimiento. No alcanza con revisar el país de destino. También hay que mirar el país de origen del pagador, el del beneficiario y cualquier jurisdicción intermediaria.
Cada cambio de país o de ruta tiene que quedar asentado en logs y alertas. Si cambia el recorrido, cambia el riesgo.
| Tipo de flujo | Límite por operación | Umbral de revisión | Monitoreo adicional |
|---|---|---|---|
| Doméstico bajo riesgo | Alto dentro del segmento permitido | Al 80% del tope acumulado | Monitoreo estándar |
| Doméstico alto riesgo | Más bajo que el flujo estándar | Revisión más temprana y frecuente | Velocidad estricta; retención ante intentos repetidos |
| Transfronterizo | Más bajo que el doméstico | Cualquier monto a ruta restringida | Screening de sanciones, validación de país y revisión manual y registro de excepción |
Cada cambio en estos parámetros tiene que versionarse, con registro del aprobador y un plan de reversión. Revisalos de forma mensual o trimestral. Y si cambian las sanciones, el riesgo de una jurisdicción o los patrones de fraude, actualizalos en el momento.
Cada excepción debe quedar registrada. El siguiente paso es definir logs, alertas y escalado.
Con los límites, el país y el screening ya definidos, todavía falta una pieza clave: la trazabilidad operativa. Después de decidir si una operación se aprueba, se retiene o se bloquea, lo que viene después marca si esa decisión se puede sostener frente a una auditoría, una revisión de cumplimiento o una disputa.
Cada transacción tiene que dejar un registro completo e inmutable. No alcanza con guardar “qué pasó”; también hay que poder explicar por qué pasó y quién lo resolvió. Los campos obligatorios, agrupados por función, son:
DD/MM/AAAA HH:MM:SS (por ejemplo, 09/09/2026 14:32:07). El timestamp se guarda en UTC y se muestra en ART.Hay un punto que no se negocia: si después hace falta corregir algo, esa corrección debe entrar como un registro nuevo. Nunca se pisa el dato original.
Cada alerta tiene que poder reconstruirse desde el log original del pago. Si alguien revisa el caso semanas o meses después, el hilo tiene que seguir intacto. Por eso, cada plantilla debe incluir:
sancion_coincidencia_exacta, limite_diario_superado, patron_estructuracionSi la alerta exige contacto con el cliente, Burbuxa puede enviar la solicitud por WhatsApp o Instagram y dejar ese intercambio vinculado al caso.
Estas son las rutas que deben disparar las alertas anteriores.
| Señal detectada | Acción operativa | Regla |
|---|---|---|
| Cliente verificado, monto dentro del límite, sin coincidencias | Aprobación automática | Sin señal de riesgo; operación dentro de los controles configurados. |
| Coincidencia exacta en lista de sanciones | Bloqueo automático + escalado | Evaluar si corresponde bloquear, rechazar o procesar. |
| Coincidencia parcial o posible falso positivo en sanciones | Revisión manual | Requiere resolución de identidad y adjudicación por evidencia. |
| Patrón AML con anomalía de velocidad o geografía sin resolver | Retención + escalado | Los casos ambiguos o vencidos suben de nivel de inmediato. |
| Incumplimiento de límite acumulado o intentos repetidos | Escalado o bloqueo por política | Cada excepción requiere decisión documentada y registro del aprobador. |
Las reglas de escalado tienen que estar por escrito, sin zonas grises: quién revisa cada alerta, en cuánto tiempo y qué pasa si ese plazo vence. Las alertas de severidad alta - sanciones, PEP, jurisdicciones restringidas - deben ir directo al responsable de cumplimiento (MLRO).
Y si alguien revierte una decisión automática, esa anulación necesita dejar tres cosas sí o sí: justificación escrita, identidad del aprobador y timestamp. Todo eso debe quedar guardado junto al registro original del pago.
Antes de activarlos, hacé una auditoría de tus flujos de datos y de cada proveedor externo. También conviene revisar el cumplimiento normativo, dejar en regla los contratos DPA y preparar webhooks junto con un endpoint HTTPS para los eventos críticos.
Además, sumá monitoreo, aplicá 3DS 2.0, definí límites y probá todo en sandbox con datos ficticios. Y algo que suele pasarse por alto: mantené logs auditables con timestamps, IDs de transacción y resultados, así tenés trazabilidad de punta a punta.
Conviene retener un pago en vez de bloquearlo cuando hay dudas sobre la legitimidad de una transacción, pero no hay pruebas claras de fraude. De esa forma, podés hacer chequeos extra sin rechazar una operación que quizá sea válida.
Esto ayuda a cuidar la tasa de conversión y a evitar roces innecesarios con el cliente. En esos casos, el modo supervisado de Burbuxa permite pausar la transacción y mandarla a revisión humana.
Llevá un registro claro y ordenado de cada transacción y de los logs de auditoría. Cada evento debería incluir, como mínimo:
Además, conservá la información de pedidos, clientes, envíos, devoluciones, decisiones de IA y los comprobantes electrónicos que exige AFIP, como el CAE y el código QR.
La idea no es guardar todo “por las dudas”. Guardá lo que haga falta para operar, revisar incidentes, responder reclamos y cumplir con AFIP, pero sin acumular datos sensibles que no suman nada. Aplicá criterios de minimización y definí plazos de retención claros desde el arranque.