Deep-dive de SG-Remesas
De los tres proyectos, SG-Remesas es el que más se parece a software financiero real, y eso cambia por completo qué es «terminado». En un CRUD normal, terminado es que el dato se guarde bien. En una plataforma de remesas, terminado es que cada cambio de estado quede registrado, que nadie mueva dinero sin permiso, y que el sistema mismo sepa cuándo algo huele raro.
La superficie pública es la parte fácil
Landing con calculadora de conversión en vivo (USD → MXN con comisión y tasa mostradas antes de confirmar), rastreo público de remesas por código (REM-2026-XF83A) sin necesidad de iniciar sesión, registro con selección de país. Nada de esto es difícil de construir. Lo interesante está del otro lado del login.
Roles que realmente restringen
El panel interno separa Admin, Auditor y Operador, y no es una etiqueta decorativa: un Operador puede aprobar o declinar transacciones desde la bandeja de «Pendientes», pero solo un Auditor puede calificar un caso de cumplimiento. Cada usuario interno queda además separado de los «Clientes» registrados — dos tablas, dos propósitos, sin mezclarse.
KYC por niveles, no por checkbox
En vez de un «verificado sí/no», cada cliente tiene un nivel — KYC-0, KYC-1, KYC-2 — y ese nivel determina límites reales de operación (kyc0_max_single_usd, kyc1_max_monthly_usd, configurables desde el propio panel, no hardcodeados). Un cliente KYC-0 recién registrado no puede mover el mismo volumen que uno ya verificado a nivel 2. Las revisiones pendientes de documento aparecen en su propia cola, con el archivo adjunto para calificar.
El motor de alertas AML no es una tabla de logs
Esta fue la parte que más disfruté diseñar: un panel de reglas activas — threshold_amount (transacción individual sobre cierto monto), structuring (3+ transacciones al mismo beneficiario en 24h que en conjunto superan un umbral, el patrón clásico de fraccionamiento para evadir controles), new_client_high_value (cliente con menos de 30 días haciendo una operación grande) — que generan alertas reales sobre las transacciones que de verdad se están procesando, no una lista simulada. Cada alerta queda en estado «Pendiente» hasta que alguien la investiga.
Trazabilidad como requisito, no como buena práctica
El historial de auditoría (identificado en el propio sistema como RF-42, un requisito con número, no una idea suelta) registra cada transición de estado por código de remesa — pending → processing, processing → failed, completed → reversed — con el operador responsable y un comentario. Es un log inmutable: no se edita, solo se agrega. Si alguien pregunta «¿quién aprobó esto y por qué», la respuesta está ahí, no en la memoria de alguien.
Comisiones configurables por par de divisas
Nada de una comisión fija global: cada par (USD→MXN, EUR→COP, GBP→MAD…) tiene su propia tasa y monto mínimo, editable desde el panel, junto con tramos de incentivo por operador según el volumen que procesan. Es la clase de detalle que separa «funciona en la demo» de «lo podrías usar para operar de verdad».
Stack
React · Node.js · Express · PostgreSQL · JWT + RBAC · Docker.
