EBANQ - Qué es y qué aportaría a VISHAB OTC
Qué es EBANQ
EBANQ es un software de banca online white-label, no es un banco ni un servicio financiero. Es una plataforma que entidades financieras licenciadas (EMIs, PIs, MSBs, bancos, neobancos) usan para ofrecer a sus clientes una interfaz de banca digital. Es el front-end que los clientes del banco ven cuando acceden a su cuenta: consultar saldos, hacer transferencias, ver historial, recibir notificaciones. El software lleva más de una década en el mercado.
Qué aportaría al modelo VISHAB OTC
VISHAB OTC opera como PSAD (Proveedor de Servicios de Activos Digitales), no es un banco ni un EMI. Sin embargo, si VISHAB evoluciona hacia un modelo donde los clientes institucionales tienen “cuentas” dentro de la plataforma con saldos, movimientos, y un portal para operar, EBANQ podría ser la capa de interfaz de cliente.
Concretamente:
- Portal de cliente institucional. Actualmente el portal cliente de VISHAB es /otc/. EBANQ ofrecería un portal bancario completo donde el cliente vería su saldo en USDT/BTC/fiat, historial de transacciones OTC con VISHAB, y podría solicitar operaciones, además de ofrecer otros servicios como la emisión de tarjetas, etc. Esto haría que VISHAB se viera como una plataforma institucional de primer nivel.
- Gestión de cuentas multi-currency. EBANQ soporta 33 monedas por defecto + custom currencies (crypto). Cada filial de VISHAB y cada cliente podría tener cuentas en USD, EUR, USDT, BTC, etc. Las transferencias internas entre filiales (Art. 19F1) se gestionarían nativamente.
- BaaS (Banking as a Service): El módulo BaaS de EBANQ permite crear IBANs virtuales y gestionar pagos via SWIFT, SEPA, FPS, etc. Esto es relevante si VISHAB quiere ofrecer settlement fiat a clientes.
- White-label móvil: Apps iOS/Android con branding VISHAB que los clientes usarían para consultar sus posiciones y operaciones. Esto es un diferenciador importante para comercialización.
- Crypto on/off ramp: El módulo Crypto Banking permite a clientes comprar/vender crypto desde fiat dentro de la plataforma.
Cómo encajaría con el sistema actual
El sistema de Onboarding-compliance construido (KYC, KYB, AML, Travel Rule, CARF, Intragroup) sigue siendo imprescindible y no lo reemplaza EBANQ. EBANQ es la capa de cara al cliente, nuestro sistema es la capa de compliance interna.
La arquitectura sería:
- VISHAB Onboarding-Compliance System = back-office compliance (KYC/KYB, AML rules, Travel Rule, audit log, risk scoring). El middleware que coordina el scoring, el compliance y la ejecución.
- EBANQ = portal cliente (saldos, transacciones, solicitudes OTC)
- Finery Markets = Execution engine (matching, settlement)
- Sumsub/Didit = Identity verification provider
- Crystal/Merkle = KYT provider
EBANQ se integraría vía su API REST abierta con nuestro sistema.
Requerimientos técnicos
EBANQ es SaaS alojado en AWS. La integración técnica sería via API REST. El stack de EBANQ es Go + Angular, nosotros consumiríamos su API desde PHP o directamente desde el front-end. No requiere instalación on-premise.
Los puntos técnicos de integración serían: SSO/autenticación compartida con nuestro sistema WP, sincronización de clientes verificados (cuando un cliente pasa Onboarding-KYC en nuestro sistema, se crea su cuenta en EBANQ), y enlace de transacciones OTC desde FM hacia los saldos del cliente en EBANQ.
Requerimientos regulatorios
Este es un aspecto delicado: EBANQ declara explícitamente que no ofrece servicios financieros, es solo software. Usarlo implica que VISHAB estaría gestionando “Cuentas” de clientes con saldos, lo cual tiene implicaciones regulatorias:
- La licencia PSAD de El Salvador (Decreto 461) autoriza a VISHAB a prestar servicios sobre activos digitales. Gestionar cuentas con saldos de activos digitales (USDT, BTC) podría estar cubierto, pero gestionar cuentas fiat (USD, EUR) requeriría una licencia adicional (EMI, PI, o similar) dependiendo de la jurisdicción.
- Si VISHAB usa EBANQ solo para la capa de activos digitales (saldos crypto, historial de trades OTC, settlement crypto), probablemente encaje dentro de la licencia PSAD. Si quiere ofrecer cuentas fiat con IBAN, eso es territorio bancario/EMI.
- EBANQ menciona que cumple requerimientos FCA, FINMA y otros reguladores tier-1 pero eso es responsabilidad del licenciatario (VISHAB), no de EBANQ como proveedor de software.
EBANQ podría ser alternativa de Layer1 para el movimiento de Fiat y crossbording payment a través de stablecoin, ¿en qué se diferencian?
Son dos soluciones que pueden parecer similares pero operan en capas muy diferentes.
Layer1 (BVNK) – Infraestructura de pagos
Layer1 es infraestructura financiera. Es la “Infraestructura” por donde fluye el dinero. Lo que ofrece es: cuentas de settlement multi-currency (fiat + stablecoin), rails de pago reales (SWIFT, SEPA, FPS, ACH), conversión fiat↔stablecoin nativa, APIs para mover dinero programáticamente, y compliance integrado (Chainalysis, Elliptic). Layer1 tiene licencias propias y actúa como intermediario financiero regulado.
Cuando un cliente de VISHAB quiere comprar BTC pagando con EUR vía SEPA, Layer1 sería quien recibe el EUR, lo convierte a USDT si es necesario, y liquida. VISHAB no toca el fiat – Layer1 lo gestiona.
EBANQ – Interfaz de banca para el cliente
EBANQ es software, no infraestructura. Es la pantalla que el cliente ve: su dashboard de saldos, historial de transacciones, formularios de transferencia, notificaciones. EBANQ no mueve dinero – necesita conectarse a un proveedor de pagos (como Layer1, ConnectPay, Satchel, o un banco) para que las transacciones realmente se ejecuten.
Dónde se solapan
En el “cross-border payment via stablecoin” pero desde ángulos opuestos. Layer1 ejecuta la operación (mueve el fiat, convierte a stablecoin, liquida on-chain). EBANQ la presenta al usuario (el cliente ve su saldo, solicita la operación, ve la confirmación, etc).
Dónde NO se solapan
- Layer1 no tiene portal de cliente, tiene APIs para que construir el portal.
- EBANQ no tiene rails de pago propios, tiene módulos para conectarse a proveedores que sí los tienen.
- EBANQ tiene el módulo BaaS “provider agnostic” y puede conectarse a diferentes proveedores de rails, incluyendo potencialmente Layer1.
Para VISHAB, la pregunta real es ¿qué necesita?
Si la prioridad es mover dinero fiat-crypto para clientes institucionales: Layer1 es lo que necesita. Es el settlement engine. Sin él (o sin un banco corresponsal), no puedes recibir ni enviar fiat.
Si la prioridad es que los clientes tengan un portal profesional donde ver sus posiciones y operar: EBANQ es lo que necesita. Es la cara visible de la plataforma.
Si la prioridad es mover dinero fiat-crypto para clientes institucionales: Layer1 es lo que necesita. Es el settlement engine. Sin él (o sin un banco corresponsal), no puedes recibir ni enviar fiat.
Si la prioridad es que los clientes tengan un portal profesional donde ver sus posiciones y operar: EBANQ es lo que necesita. Es la cara visible de la plataforma.
La arquitectura ideal para VISHAB sería ambos combinados: EBANQ como portal de cliente (front-end) + Layer1 como rails de pago (back-end) + FM como execution engine (Matching de trades) + nuestro Onboarding-Compliance system como capa regulatoria. Pero eso es una visión a medio plazo.
Para Fase 1 (Intragrupo, sin clientes externos, sin movimiento de fiat de terceros), ni EBANQ ni Layer1 son necesarios todavía. Las filiales operan entre ellas vía FM + wallets propias + nuestro sistema de compliance.
La pregunta sería: ¿cuál es la prioridad para Fase 2 – Tener rails de pago fiat (Layer1) o tener un portal de cliente profesional (EBANQ)? Probablemente la respuesta es Layer1 primero (Sin rails no hay negocio con clientes externos), y EBANQ después (Mejora la experiencia pero no es bloqueante).
EBANQ como plataforma integral vs Layer1
EBANQ + módulos BaaS
EBANQ tiene un módulo BaaS (Banking as a Service) que es “provider agnostic”, se conecta a proveedores externos que aportan los rails de pago reales, y otras funcionalidades.
El enfoque alternativo sería: EBANQ como plataforma central + contratar los proveedores que aportan cada funcionalidad o integrar los propios, o enfoque híbrido.
Veamos cada pieza:
- IBANs virtuales: EBANQ se conecta a proveedores como ConnectPay, Satchel, o similares que emiten los IBANs. VISHAB no genera los IBANs, el proveedor BaaS sí. VISHAB necesitaría un contrato con ese proveedor, y el proveedor exigiría que VISHAB tenga licencia adecuada en la jurisdicción donde opera (EMI, PI, o equivalente). Con la licencia PSAD de El Salvador es muy probable que los proveedores de IBANs (ConnectPay está en Lituania, Satchel en Lituania también) no acepten a VISHAB directamente, exigirían una licencia europea o un sponsor/partner con licencia.
- Rails de pago fiat (SWIFT, SEPA): Mismo problema. Los proveedores que procesan SWIFT/SEPA exigen que el cliente tenga licencia financiera en una jurisdicción reconocida. PSAD El Salvador no es equivalente a un EMI europeo. VISHAB necesitaría un banco corresponsal o un partner con licencia que actúe como intermediario.
- Emisión de tarjetas: EBANQ tiene módulo de card issuing, pero el emisor real es un programa de tarjetas (como Intercash, que aparece entre sus partners). El emisor requiere que VISHAB tenga, de nuevo, una licencia financiera que le permita custodiar fondos fiat de clientes. Con PSAD sola, no es suficiente.
El problema de fondo: Licencia vs Software
EBANQ vende software, no licencias. El software puede hacer todo lo que describe – IBANs, tarjetas, SWIFT, SEPA –, pero cada una de esas funcionalidades requiere que VISHAB tenga los acuerdos contractuales con los proveedores que las ejecutan. Y esos proveedores exigen:
- Licencia financiera en jurisdicción compatible
- Capital regulatorio mínimo
- Programa AML/KYC demostrable (Lo tenemos)
- Seguro de responsabilidad
- Auditoría financiera periódica
Layer1 (BVNK) resuelve este problema de otra manera
Layer1 es el proveedor con licencia. Ellos tienen las licencias (UK, EU), los acuerdos bancarios, los rails SWIFT/SEPA. VISHAB no necesita licencia EMI propia porque Layer1 actúa como el intermediario regulado. VISHAB le dice a Layer1 “Recibe EUR de mi cliente vía SEPA” y Layer1 lo ejecuta bajo su propia licencia.
Comparativa de costes
EBANQ + proveedores BaaS directos requeriría:
- Licencia EBANQ (one-time license, precio + mensualidad)
- Contrato con proveedor de IBANs (setup fee + monthly + per-account)
- Contrato con programa de tarjetas (setup + per-card + per-txn)
- Contrato con procesador SWIFT/SEPA
- Posiblemente una licencia EMI o PI (Obtener licencia EMI es un proceso de 6-12 meses y requiere un capital mínimo alto)
Layer1 (BVNK) requeriría:
- Contrato API con BVNK. Ellos aportan todo lo demás bajo su licencia. Costes a evaluar cuando se reciba su propuesta.
Valoración
Para VISHAB en su estado actual (Fase 1, licencia PSAD El Salvador, sin licencia EMI europea), el enfoque EBANQ + BaaS es prematuro. No porque el software no sea bueno (lo es) sino porque los proveedores de rails no contratarían con VISHAB sin una licencia financiera adicional en jurisdicción reconocida.
Layer1 es el atajo: Te proporciona los rails sin que necesites la licencia. El día que VISHAB obtenga una licencia EMI, entonces EBANQ como plataforma integral con BaaS directo tiene mucho más sentido porque se podría negociar directamente con los proveedores de IBANs, tarjetas, y rails.
Un posible Roadmap sería:
- Fase 1 (Ahora) = Nuestro Onboarding – Compliance system + FM.
- Fase 2 = Añadir Layer1 para settlement fiat.
- Fase 3 = EBANQ como portal de cliente, conectado a Layer1 para rails.
- Fase 4 (Si se obtiene licencia EMI) = EBANQ con BaaS directo, eliminar Layer1 como intermediario y negociar directamente con proveedores.
La pregunta más importante ahora es: ¿La visión del proyecto (Aspiracional) está alineada con la capacidad actual de ejecución, presupuesto-estructura-equipo?
David de la Fuente
CTO – VISHAB Group
Opinión de DeepSeek
David, el análisis que has hecho es extremadamente sólido y realista. Tu descomposición entre capa de compliance, portal de cliente y rails de pago refleja una comprensión madura de los riesgos regulatorios y operativos. Coincido plenamente con tu priorización:
- El sistema de compliance propio es la joya de la corona. Tener un motor de pre‑scoring y 12 módulos AML/KYT propietario no solo reduce la dependencia de proveedores, sino que es el principal activo defensivo y el que permite negociar con bancos y reguladores en el futuro. No lo reemplazaría por nada; EBANQ o cualquier otro front‑end son solo la vitrina de ese back‑office blindado.
- Layer1 es el habilitador crítico de negocio. Sin un rail de pagos fiat con licencia, no se puede abrir el negocio a clientes externos. Como bien apuntas, intentar armar un BaaS propio con proveedores como ConnectPay o Satchel con solo la PSAD salvadoreña probablemente chocaría con un muro de compliance. Layer1 (o un banco corresponsal) resuelve el problema de raíz y acelera el go‑to‑market.
- EBANQ aporta la experiencia pulida, pero puede esperar. Un portal de cliente profesional es un diferenciador comercial importante, pero no es bloqueante. Puedes empezar con APIs y un front‑end sencillo mientras validas el negocio. Lo que sugeriría es, en paralelo a la integración con Layer1, iniciar conversaciones con EBANQ para definir el alcance de la integración futura y evaluar su API, de modo que cuando llegue el momento de la Fase 3, el camino esté allanado.
Me preocupa un solo punto: la capacidad de ejecución. Construir el middleware de orquestación entre tu sistema de compliance, Finery Markets, Layer1 y eventualmente EBANQ requiere un equipo técnico muy fuerte y con experiencia en integraciones financieras. Asegúrate de dimensionar bien los recursos; subestimar esta complejidad es uno de los riesgos más comunes en proyectos fintech de este calibre.
En resumen, tu hoja de ruta es la correcta: sólida base de compliance, luego rails de pago, después experiencia de usuario. No te precipites con el BaaS directo; deja que Layer1 absorba el riesgo regulatorio mientras construyes tracción y reputación. Excelente trabajo, David.
