BCRA A 8477: límites UVA y prueba de transferencias
La actualización del BCRA mueve límites en UVA y corrige puntos del sistema de transferencias. Guía para guardar evidencia, permisos y prueba diaria.
Límites UVA, solicitudes de pago y puntos 2.9 y 2.10: la Comunicación “A” 8477 del BCRA volvió a cambiar la carpeta técnica de transferencias para bancos, redes y PSP. La norma incorpora hojas nuevas al texto ordenado del Sistema Nacional de Pagos y corrige una actualización previa. Esta nota muestra qué dato debe quedar trazado, dónde guardarlo y cómo probar que una transferencia pudo explicarse después.
Qué cambia para bancos, PSP y comercios que cobran por transferencia
El cambio operativo aparece en los valores que las mesas de pago miran todos los días. La Comunicación “C” 102183 fijó, al 31 de julio de 2026, una equivalencia UVA de $2.057,99: 15.000 UVA representan $30.870.000 para el límite mínimo diario de transferencias inmediatas push y 2.500 UVA representan $5.145.000 para pull. Esa cifra corrige la costumbre de cargar topes fijos dentro de una planilla. El antagonista concreto es el PDF viejo guardado en una carpeta compartida, con un rótulo amarillo que dice “usar hasta nuevo aviso”. Si ese archivo queda vivo, el área de Tesorería puede aprobar una transferencia con una regla vencida y soporte queda obligado a reconstruir el caso con capturas, correos y memoria de guardia. La escala local entra en una tendencia más amplia: la encuesta Stack Overflow 2025 muestra que SQL aparece en el 58,6% de las respuestas de tecnologías usadas. En pagos, ese dato importa porque el control termina escrito en consultas, reportes y tablas de auditoría, aunque la orden empiece en una app bancaria. Una norma de pagos se vuelve operativa cuando deja una huella legible.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, el cliente inicia una transferencia push, pull o una solicitud de pago. Segundo, el banco o PSP recibe CBU, CVU, CUIT, alias, monto, moneda, hora y canal. Tercero, una tabla de reglas guarda la versión normativa aplicada, el valor UVA de referencia y el tipo de operación. Cuarto, PostgreSQL guarda registros estructurados: identificador de operación, estado, respuesta del sistema, usuario técnico y marca temporal. PostgreSQL recibe filas de eventos y devuelve una historia consultable para soporte, cumplimiento y conciliación. Quinto, un servicio valida si la transferencia supera el límite configurado y devuelve aprobar, rechazar o revisar. Sexto, Metabase muestra excepciones por día y por rol; toma consultas SQL autorizadas y entrega tableros separados para Tesorería, soporte y auditoría. El acceso se controla por grupos. Keycloak recibe usuarios y pertenencias, emite tokens y permite separar quién lee, quién edita reglas y quién exporta evidencia. Los comprobantes, anexos y cortes diarios pueden guardarse en MinIO/S3; ese almacenamiento recibe archivos grandes, conserva metadatos y permite probar una restauración sin mezclar binarios dentro de la base.
Qué se instala o configura primero
Una implementación razonable empieza con una tabla de parámetros normativos, otra de operaciones y otra de eventos. Después se agrega un job que toma el valor vigente de UVA o el archivo validado por Legales, registra la versión y genera un hash del insumo. El primer entregable verificable es un reporte diario con diez operaciones de muestra, cada una con regla aplicada, usuario consultante y resultado. Con dólar oficial vendedor a $1535, una VM chica para base y tablero puede costar entre USD 25 y USD 45 mensuales, unos $38.000 a $69.000 antes de impuestos y soporte. El cálculo incluye servidor, backup y monitoreo básico; deja afuera horas de análisis legal y cambios en el core de pagos. UMSA suele encarar este tipo de ordenamiento desde el borde operativo: qué archivo se usa, qué tabla lo recibe, qué rol puede cambiarlo y qué prueba deja a la gerencia tranquila. En una pyme exportadora o una cámara que cobra cuotas por transferencia, ese primer corte evita discusiones largas cuando un pago queda observado.
Dónde se rompe y cómo probarlo
El primer riesgo es cargar un valor UVA sin fecha de vigencia. La señal aparece cuando dos reportes calculan límites distintos para el mismo día. La prueba previa es ejecutar una operación de $30.870.001 contra la regla del 31/07/2026 y comprobar que queda observada. El segundo riesgo es permitir que soporte edite parámetros. La señal aparece cuando el registro de auditoría muestra cambios fuera del grupo autorizado. La prueba es usar una cuenta de soporte, intentar cambiar el límite y revisar que el sistema rechace la acción. El tercer riesgo es respaldar solo PostgreSQL y olvidar comprobantes. La señal aparece en una restauración donde vuelve la fila, pero falta el archivo. La prueba mínima restaura base y MinIO/S3 en un entorno vacío y abre tres operaciones completas. La revisión mensual compara esas tres pruebas contra la norma vigente y deja firmado el responsable. El cierre verificable llega cuando un pago puede explicarse con fecha, regla, usuario y evidencia, sin pedirle a soporte que recuerde una excepción de madrugada.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.