← Todos los productosProducto · Infraestructura · Bancos y fintechs
Blockchain como un módulo del banco, no un proyecto aparte
Wallets custodiadas, pagos en stablecoin y un motor de compliance, detrás de una sola API.
- Origen
- Producto propio de Caramel
- Industria
- Bancos y fintechs
- Modelo
- Sin costo de licencia; se cobra la implementación
El problema
A un banco le piden hoy lo que hace dos años era experimental: mover stablecoins, custodiar activos digitales, liquidar en minutos y no en días. Construirlo adentro no es un proyecto sino tres: un equipo que sepa de cadenas, un esquema de custodia de claves que el área de riesgo acepte, y un relato de prevención de lavado que resista una auditoría.
Cada uno de los tres se puede resolver. El problema es que hay que resolverlos juntos, antes de mover el primer peso, y que ninguno se parece a lo que el core bancario ya sabe hacer.
La respuesta
Riel pone esas tres cosas detrás de una sola API. El banco pide una wallet, ordena un pago o consulta una actividad con llamadas REST, y del otro lado quedan la wallet con sus claves encriptadas, la transacción on-chain y el registro que la explica.
El compliance no es un chequeo posterior: corre dentro del camino de la transacción. Antes de que una operación se confirme pasa por reglas configurables, por patrones temporales y por screening contra listas de sanciones, y sale con un score de riesgo y, si corresponde, con una alerta abierta.
El gas lo cubre la plataforma. El usuario final no tiene que entender qué es una red ni mantener saldo en otra moneda para poder mover la suya: ve una operación de su banco.
Qué construimos
Seis módulos que comparten la misma API y el mismo panel. El banco integra el que necesita y suma los demás cuando quiere, sin rehacer la integración.
Wallets custodiadas
Las claves se guardan encriptadas y la wallet se crea sola en la primera operación del usuario. El cliente no ve una dirección si el banco no decide mostrársela.
Claves encriptadas con AES-256-CBC
Pagos y solicitudes
Transferencias entre usuarios, solicitudes de cobro con vencimiento y conversión de pesos a stablecoin con cotización propia. El historial llega unificado y con filtros.
Cotización con vencimiento de 60 s
Gas abstraction
El paymaster de la plataforma paga la comisión de red de cada operación. Es la diferencia entre un producto que el cliente usa y uno que abandona en el primer intento.
Cero gas para el usuario final
Motor de compliance
Tres capas dentro del camino de la transacción: reglas configurables, patrones temporales —fraccionamiento, velocidad, anomalías de volumen— y screening contra listas de sanciones.
Reglas evaluadas en menos de 10 ms
Circuit breakers
Interruptores automáticos ante pérdida de paridad de la stablecoin, anomalías de volumen, tasa de errores o caída de la tesorería. Cortan antes de que alguien mire el panel.
4 disparadores automáticos
Panel de administración
Indicadores, balances de las wallets del sistema, listado y exportación de transacciones, actividad en vivo y el workflow de alertas: nueva, en revisión, resuelta.
Alertas con workflow de revisión
Lo que demostramos
- 3
- Capas de complianceReglas, patrones temporales y sanciones
- <10 ms
- Evaluación de reglasLa primera capa, sincrónica, dentro de la transacción
- 8
- Factores de scoringPonderados, con score de 0 a 100 en cuatro tiers
- 4
- Circuit breakersParidad, volumen, tasa de errores y tesorería
Las cuatro cifras describen el motor, no una operación: son los parámetros con los que el compliance corre dentro de cada transacción.
La superficie técnica
Una integración, no seis. Estos son los puntos que consume el banco; el panel de administración usa los mismos.
ImplementadoLa API de la plataforma
REST, con autenticación por token
- POST /api/v1/quotes
- Cotización de pesos a stablecoin, con vencimiento.
- POST /api/v1/transfers
- Transferencia entre usuarios, con el gas cubierto.
- POST /api/v1/payments/requests
- Solicitud de cobro con vencimiento, para que la pague otro usuario.
- GET /api/v1/users/:id/activity
- Historial unificado de compras, envíos y pagos, con filtros.
- GET /api/v1/admin/compliance/rules
- Las reglas de compliance que configura el equipo del banco.
- GET /api/v1/admin/compliance/alerts
- Las alertas abiertas y su estado de revisión.
Honestidad por diseño
El screening de sanciones corre contra listas —OFAC, Unión Europea, Naciones Unidas y UIF— con comparación difusa por nombre. No hay analítica on-chain de un proveedor externo detrás: si el banco la necesita, se integra, pero no viene incluida.
Las reglas las define el equipo de compliance del banco, no nosotros. Riel trae el motor y el panel para escribirlas, evaluarlas y auditarlas; el criterio es del área que responde por él. La custodia de las claves también se acuerda: puede quedar en el banco, en nosotros o repartida entre los dos.
Cómo lo hacemos en Caramel
Advise
Relevamiento de la operación, mapeo de integraciones y definición de las reglas de riesgo junto al área de compliance, antes de escribir código.
Build
La integración con los sistemas del banco, la configuración de la instancia y el panel desde el que el equipo opera sin pedirle nada a desarrollo.
Run
Monitoreo de la plataforma, de las wallets del sistema y de los circuit breakers, y la evolución de las reglas cuando cambia la normativa.
Architect-led · Engineer-built · Production-proven
Stack
- Node.js
- TypeScript
- Express
- Prisma
- PostgreSQL
- ethers.js
- Polygon
- React
¿Lo evaluamos con tus datos?
Pedir una demo