Backend de neobanco cripto con una sola API key
Un neobanco que muestra saldos en cripto necesita tres cosas a la vez: leer el patrimonio de cada cuenta, decidir si acredita o libera fondos en el ramp, y desembolsar a muchos destinatarios. El patrón habitual resuelve cada pieza con un proveedor distinto, y eso multiplica contratos, conciliaciones y puntos de fallo. Aquí la arquitectura de referencia junta lectura de balances, screening en el borde y payout sobre nodos propios de archivo, con una única key y un único saldo prepago en credits.
El desafío
El equipo suele arrancar con tres integraciones separadas: una API de balances para el net-worth, un proveedor de screening/AML para el ramp y un rail de pagos para los desembolsos. Cada una tiene su key, su modelo de facturación y su latencia. El resultado es que el momento crítico —acreditar un depósito o liberar un retiro— depende de que dos servicios externos respondan a tiempo, y la tesorería del producto se fragmenta en saldos que no se hablan entre sí. Además hay que decidir dónde va cada control: el screening tiene que ejecutarse antes de acreditar, mientras que el KYT vigila la actividad que ya quedó asentada.
- Balances / portfolio / net-worthC2
- Address risk-score / exposureC3
- Transaction screening / KYTC3
- Mass payout / settlementC2
Patrimonio por cuenta en una sola lectura
Cada cuenta del neobanco consulta su net-worth agregado en BTC, ETH y TRON con una llamada, sin mantener un indexador por cadena ni reconstruir saldos a mano. La lectura sale de nodos de archivo propios, así que el histórico está disponible para estados de cuenta y para recalcular posiciones sin depender de un tercero que revenda RPC.
Screening en el borde del ramp, KYT sobre lo asentado
En el on-ramp y off-ramp se corre risk-score y screening de sanctions antes de acreditar o liberar: la wallet contraparte se evalúa en el borde, y solo si pasa el control avanza el movimiento. El KYT queda como capa de monitoreo continuo sobre la actividad ya registrada, con decisión de tipo allow/review/block que puedes archivar para auditoría.
Desembolsos masivos contra el mismo saldo
Los pagos a muchos destinatarios se hacen con mass payout usando la misma key. La construcción de la transacción se hace del lado de la plataforma, pero la firma queda del lado del cliente: no custodiamos keys. Como balances, screening y payout consumen el mismo saldo en credits, la contabilidad del backend deja de repartirse entre tres facturas.
Lo que entrega la arquitectura
- Un solo contrato, una key y un saldo en credits en lugar de tres proveedores para balances, screening y payout.
- El control AML queda en el sitio correcto: screening antes de acreditar en el ramp y KYT vigilando la actividad ya asentada.
- Net-worth multi-cadena y desembolsos masivos consultan la misma fuente de nodos propios, sin conciliar saldos entre servicios externos.
Preguntas frecuentes
¿Custodian ustedes las private keys de las wallets del neobanco?
No. La plataforma construye la transacción de payout, pero la firma se hace del lado del cliente con su propio esquema (MPC, multisig o lo que use). Nunca vemos ni almacenamos las keys.
¿En qué se diferencia el screening del ramp del monitoreo KYT?
El screening corre en el borde del on-ramp/off-ramp y decide antes de acreditar o liberar fondos. El KYT observa la actividad que ya quedó asentada para detectar riesgo emergente sobre cuentas activas.
Recarga, obtén tu clave y publica.
Autoservicio. Paga en cripto o con tarjeta. Medido por créditos: las primitivas pesadas cuestan más, las simples son baratas.
Obtener clave API