Arquitectura de la plataforma
Un núcleo, muchas superficies: cómo funciona realmente la plataforma.
Un recorrido por la plataforma desde el libro mayor: las cuentas, el KYC, las tarjetas y las criptomonedas que comparten un único núcleo de partida doble, cómo avanza un pago desde la creación hasta la conciliación y dónde se sitúan la capa de aplicaciones, la consola de operador y la frontera regulada.
El núcleo
Un único libro mayor bajo todo.
En el centro de la plataforma hay un único libro mayor de cuentas. Cada cuenta (el monedero de un cliente, el saldo de un comercio, una cuenta de comisiones, una cuenta de liquidación) es un nodo de ese libro, y cada movimiento de valor es un asiento de partida doble: una cuenta se adeuda, otra se abona y ambos lados siempre coinciden. El libro mayor es de solo adición. Los asientos nunca se editan ni se eliminan; una corrección es un asiento nuevo de signo contrario, de modo que siempre se puede reconstruir el historial completo de cómo un saldo llegó a su valor actual. Las cuentas, el estado de KYC, las tarjetas emitidas y las direcciones cripto se asocian al mismo modelo de cuenta, y por eso una autorización de tarjeta, una transferencia bancaria y un depósito on-chain pueden contabilizarse en un mismo saldo sin una capa de conciliación que una sistemas separados.
- 01Partida doble: cada asiento cuadra, el debe iguala al haber
- 02Solo adición: las correcciones son asientos nuevos, nunca ediciones
- 03Un único modelo de cuenta para fiat, tarjetas y cripto
- 04El estado de KYC viaja con la cuenta, no en una tabla aparte
Un pago, de principio a fin
Un pago, de la creación a la conciliación.
Un pago no es una sola llamada, sino un ciclo de vida breve, y cada etapa es un estado que pueden ver tanto el libro mayor como tus sistemas. Cada cambio de estado emite un webhook y cada escritura es idempotente: la misma clave devuelve el mismo resultado, así que una petición reintentada nunca cobra dos veces.
- 01
Crear
Se abre una intención de pago: importe, divisa y cuentas implicadas. Aún no se ha movido nada; el libro mayor registra un asiento pendiente.
- 02
Autorizar
La red comprueba fondos y riesgo y aplica una retención. En una tarjeta es la autorización; en una transferencia, se reserva el adeudo.
- 03
Capturar
Se confirma el importe retenido. El libro mayor contabiliza el asiento de partida doble que realmente mueve el valor entre las dos cuentas.
- 04
Liquidar
Los fondos se compensan en la red subyacente (esquema de tarjetas, banco o cadena) y las cuentas de liquidación se concilian con dinero real.
- 05
Conciliar
La plataforma contrasta sus propios asientos con el informe de liquidación de la red; lo que no cuadra se señala, no se oculta.
Los webhooks y la idempotencia están presentes en cada extremo de este flujo. Tus sistemas saben que un pago se ha movido porque reciben un evento, no por polling, y cualquier petición que reintentes tras un timeout se resuelve, mediante su clave de idempotencia, con el mismo resultado, de modo que una repetición nunca cobra dos veces. El servicio que ejecuta la autorización y la captura es la pasarela de pago.
La capa de aplicaciones
Apps whitelabel arriba, una sola plataforma debajo.
El núcleo expone capacidades; la capa de aplicaciones las convierte en productos. Cada app de cara al cliente, web y móvil, es un cliente whitelabel que muestra las mismas cuentas, pagos y tarjetas bajo su propia marca. La personalización visual se basa en tokens: colores, tipografía, radios y espaciados provienen de un sistema de design tokens (PDS), de modo que un operador rediseña toda la superficie cambiando tokens, sin bifurcar la app. La misma plataforma puede orientarse en direcciones muy distintas (un neobanco para consumidores, una app de adquirencia para comercios, un programa de emisión de tarjetas, una on/off-ramp cripto o una herramienta interna de operaciones) sin convertirse en cinco productos separados. Es una plataforma con distintos aspectos, cada uno configurado en lugar de reconstruido.
- 01Clientes web y móvil whitelabel sobre APIs compartidas
- 02Temas basados en tokens (PDS): se rediseña por configuración, no por fork
- 03Cinco ejemplos de orientación: neobanco, adquirencia, emisión, ramp y ops
- 04Las nuevas superficies se configuran, no se reconstruyen
Operaciones
Se gestiona desde la consola, con un motivo registrado.
Detrás de cada app hay una consola de operador. Es donde un agente de soporte consulta una cuenta, un analista de riesgo bloquea una tarjeta o un responsable de operaciones revierte un asiento. El acceso de lectura es amplio; las acciones privilegiadas, no. Cualquier acción que mueva dinero, cambie límites o afecte a los fondos de un cliente exige indicar un motivo antes de ejecutarse y genera un registro de auditoría inmutable: quién actuó, sobre qué, cuándo y por qué. El acceso sigue el principio de mínimo privilegio, así que cada operador ve y hace solo lo que su rol permite. Este es el modelo de Protocore Center, la consola de operador, y la misma filosofía está integrada en todos los sistemas de la plataforma: las acciones sensibles son deliberadas, atribuibles y revisables a posteriori.
- 01Lectura amplia, escritura restringida: las acciones privilegiadas son la excepción
- 02Motivo obligatorio antes de cualquier acción que afecte a fondos
- 03Auditoría inmutable: quién, qué, cuándo y por qué
- 04Mínimo privilegio por rol de operador
El puente cripto
Cripto y fiat en el mismo libro mayor.
En la plataforma, las criptomonedas no son un silo aparte; una dirección cripto es simplemente otra cuenta del mismo libro mayor. Una on/off-ramp convierte entre fiat y activos digitales en el borde: el cliente recarga un saldo con tarjeta o transferencia y recibe cripto, o vende cripto y retira a una cuenta bancaria. El valor on-chain puede liquidarse hasta llegar a una red bancaria: un pago on-chain entrante se abona en la cuenta, se convierte y se paga a un IBAN, de modo que el destinatario ve dinero normal en una cuenta bancaria normal. Como ambos tramos se contabilizan en un único libro de partida doble, un movimiento que empieza on-chain y termina en una transferencia bancaria es un único historial conciliado, no dos sistemas conciliados a mano.
- 01Una dirección cripto es una cuenta como cualquier otra
- 02On/off-ramp: fiat y activos digitales convertidos en el borde
- 03Liquidación on-chain hasta el pago a un IBAN
- 04Un único historial conciliado en ambos tramos
La superficie de desarrollo
APIs, webhooks y un sandbox para desarrollar.
Todo lo que hacen las apps lo hacen a través de una API documentada: crear una cuenta, abrir un pago, emitir una tarjeta, iniciar una ramp. Ejemplos ilustrativos de llamadas son POST /v1/wallets o POST /v1/payments; el estilo es REST, con una clave de idempotencia en cada escritura. Los cambios de estado se entregan como webhooks, para que tus sistemas reaccionen a eventos en lugar de consultarlos con polling. El desarrollo se hace sobre un tenant sandbox, una copia aislada de la plataforma con redes de prueba, donde puedes ejecutar el flujo completo, de la creación a la conciliación, sin mover dinero real. Lo que cada producto te expone, y en qué nivel, lo define su banda de acceso; las páginas de cada producto detallan qué incluye cada banda.
- 01API REST documentada, escrituras idempotentes
- 02Webhooks para cada cambio de estado: basado en eventos, sin polling
- 03Tenant sandbox con redes de prueba, aislado de producción
- 04Alcance y límites definidos por bandas de acceso de cada producto
El límite, sin rodeos
Protocore construye el software. La licencia sostiene la frontera regulada.
Un producto de pagos son dos cosas unidas: el permiso regulado para custodiar y mover dinero, y el software que lo ordena, lo registra y lo concilia. Protocore construye el software. La actividad regulada (custodiar fondos de clientes, emitir cuentas, mover dinero en una red de pagos) corresponde a la licencia propia del operador o a un socio con licencia: un banco, una EMI o una entidad de pago. La plataforma está pensada para encajar en las redes reguladas que aportes y para mantener los datos de tarjeta en la red, de modo que nunca pasen por tus servidores; no sustituye ese permiso, ni tampoco lo hace ningún software. Dónde se traza la frontera regulada es una decisión que tomas junto con tu socio, y la arquitectura está diseñada para quedar limpiamente a cualquiera de los dos lados.
- 01Una capa de software, no una licencia
- 02La actividad regulada recae en el operador o en un socio con licencia
- 03Los datos de tarjeta se quedan en la red, fuera de tus servidores
- 04Diseñada para encajar en las redes reguladas que aportes
Dónde conecta esto
Sigue tirando del hilo.
Cada concepto de esta página tiene un lugar más completo: las definiciones, los productos y las bandas de acceso que detallan qué incluye cada nivel.
Idempotencia, webhooks, liquidación, IBAN virtual, SCA: definidos.
El servicio que ejecuta la autorización y la captura.
Acciones privilegiadas con motivo obligatorio y auditadas.
Valor on-chain liquidado hasta un IBAN.
Fiat y activos digitales convertidos en el borde.
Qué incluye cada producto, nivel por nivel.
¿Quieres la arquitectura para tu proyecto?
Cuéntanos qué estás construyendo. Volveremos con un diseño de sistema y con el punto donde se sitúa la frontera regulada, no con una presentación comercial.