Requisitos de una plataforma bancaria de tokenización

Una plataforma bancaria de tokenización no debería evaluarse como una herramienta para acuñar tokens. El requisito útil es una capa operativa controlada por el banco que conecte los canales de clientes, el sistema bancario central, las decisiones de cumplimiento, los proveedores de custodia o firma, la liquidación, la conciliación y la evidencia de auditoría sin crear una segunda fuente de verdad.

Esta lista convierte ese requisito en preguntas de diseño verificables. Está dirigida a equipos de producto, operaciones, cumplimiento, riesgo, seguridad y tecnología que preparan el descubrimiento o la evaluación de proveedores. Es un marco de diseño operativo, no una afirmación de que todos los bancos necesiten la misma arquitectura ni de que se aplique un perímetro jurídico o regulatorio concreto.

Empiece por el modelo operativo, no por la lista de activos

Un documento de requisitos débil empieza por activos y redes: qué tokens, qué cadenas y qué carteras. Un documento más sólido empieza por decisiones y registros:

• ¿Qué sistema bancario sigue siendo autoritativo para la identidad del cliente, el estado de la cuenta, los límites y los saldos?
• ¿Quién puede iniciar, aprobar, retener, liberar, cancelar o anular cada transacción?
• ¿Qué parte mantiene los activos o las claves y cuál solo enruta instrucciones?
• ¿Cuándo se considera que una transacción está pendiente, ejecutada, liquidada, contabilizada, conciliada o fallida?
• ¿Qué evidencia debe conservarse para operaciones, cumplimiento, auditoría interna y externa y revisión de incidentes?
• ¿Qué funciones permanecen desactivadas hasta que las aprueben los responsables internos, el asesoramiento jurídico cualificado y los proveedores debidamente autorizados?

La secuencia importa porque la tokenización añade una nueva superficie de ejecución y registro a un banco existente. No debería crear una empresa operativa paralela oculta dentro de una función del producto.

Antes de elegir un modelo de despliegue, los equipos pueden utilizar la evaluación de preparación de Asset Haus para encuadrar el perímetro de decisión y la comparación de modelos de despliegue para separar SaaS, marca blanca, híbrido y opciones controladas por el cliente. Estos recursos están en inglés.

Requisito 1: defina los registros autoritativos

El primer requisito no es la selección de la cadena de bloques. Es un mapa de fuentes de verdad.

Para cada objeto de datos, identifique el sistema autoritativo, las réplicas permitidas, la dirección de actualización, la frecuencia de conciliación, el responsable de excepciones y la regla de conservación. Entre los objetos típicos se incluyen:

Objeto de datos	Pregunta del requisito	Evidencia de aceptación
Identidad del cliente	¿Qué maestro de clientes controla el acceso y el estado?	Mapa de campos, matriz de responsabilidad y registros de prueba
Saldo de cuenta en moneda fiduciaria	¿Qué libro mayor central autoriza débitos y créditos?	Especificación de contabilización y casos de prueba equilibrados
Posición en activos digitales	¿Qué registro es operativo y cómo se concilia con proveedores y redes?	Informe de conciliación de posiciones
Registro de inversores o titulares	¿Qué registro determina la titularidad reconocida del instrumento?	Diseño de registro aprobado y proceso de excepciones
Estado de la transacción	¿Qué eventos trasladan la transacción entre estados?	Máquina de estados versionada y registro de eventos
Documentos y consentimientos	¿Qué versión controló la decisión del cliente o inversor?	Referencias inmutables a documentos y consentimientos

“En cadena” no significa automáticamente autoritativo desde el punto de vista jurídico, completo en términos operativos ni conciliado. El saldo de un token puede ser uno de varios registros. La jerarquía correcta depende del producto, la documentación, las partes y la jurisdicción. La guía relacionada sobre el registro oficial de valores tokenizados desarrolla esta distinción; está disponible en inglés.

Un requisito verificable podría indicar: “Para cada movimiento liquidado, la plataforma puede producir la instrucción del cliente, la cadena de aprobaciones, la respuesta del proveedor, la referencia de red cuando corresponda, la contabilización en el libro principal y el resultado de conciliación bajo un identificador de transacción único”.

Requisito 2: integre de forma bidireccional con el sistema bancario central

Una exportación unidireccional rara vez es suficiente. La plataforma necesita un patrón de integración controlado tanto para los datos que alimentan decisiones como para los resultados de contabilización.

La información entrante puede incluir el estado del cliente, la titularidad de la cuenta, saldos, límites, permisos de producto, firmantes autorizados y restricciones de riesgo. La información saliente puede incluir reservas, comisiones, asientos de liquidación, reversiones, actualizaciones de posición y estados de excepción.

Los requisitos deberían definir:

1. llamadas síncronas y asíncronas;
2. idempotencia y tratamiento de duplicados;
3. fechas contables y de valor;
4. condiciones de firmeza antes de contabilizar;
5. lógica de reversión y compensación;
6. comportamiento en modo degradado;
7. controles de reparación manual;
8. cortes y responsabilidad de la conciliación.

Evite “se integra con el sistema bancario central” como un único punto. Exija esquemas de mensajes, transiciones de estado, códigos de error, política de reintentos, expectativas temporales y escenarios de prueba firmados. La prueba de aceptación no es una llamada API correcta por el camino feliz; es una contabilización integral equilibrada con tratamiento conocido de duplicados, tiempos de espera, confirmaciones tardías y transacciones rechazadas.

Requisito 3: separe orquestación, custodia y firma

Un proveedor de custodia puede ser esencial, pero la custodia no es toda la capa operativa. La plataforma todavía debe coordinar canales, política bancaria, derechos del cliente, aprobaciones, casos de cumplimiento, contabilidad, conciliación e informes.

Los requisitos deberían distinguir al menos cuatro responsabilidades:

• Custodia de activos o servicio de cartera: la parte y el sistema que mantienen o administran activos o carteras.
• Control de claves y firma: el límite de seguridad, la política y el proceso de aprobación que autorizan firmas.
• Orquestación de transacciones: el sistema que evalúa la solicitud, obtiene decisiones, selecciona una ruta y sigue el estado.
• Registros bancarios: los sistemas que contabilizan registros financieros y de clientes y producen extractos e informes.

No suponga que estas responsabilidades pertenecen a un solo proveedor. El diseño puede utilizar un custodio externo, una ruta de firma controlada por el banco, varios proveedores o un modelo híbrido. El requisito de la plataforma es conservar la política y la evidencia a través de esos límites.

La abstracción de proveedores también debe ser real, no cosmética. Pregunte si la lógica de enrutamiento, los identificadores, los modelos de error, los saldos, las comisiones, las referencias de liquidación y los procedimientos de interrupción permiten incorporar un segundo proveedor sin reescribir la experiencia del cliente. La guía de infraestructura de custodia de activos digitales ofrece un marco más amplio; el requisito bancario aquí es la integración operativa, no una recomendación de custodia. La guía está en inglés.

Requisito 4: convierta el cumplimiento en una cadena de decisiones

“KYC integrado” no es un requisito de cumplimiento completo. Un banco necesita saber qué decisiones se producen, en qué orden, con qué datos, con qué códigos de motivo y bajo qué autoridad.

Una cadena de decisión de transacciones puede incluir:

• controles de identidad y estado de la cuenta;
• elegibilidad de producto y jurisdicción;
• límites del cliente, la cuenta y la transacción;
• detección de sanciones y AML;
• controles de beneficiario y dirección;
• intercambio de información del originador y el beneficiario cuando corresponda;
• aprobación maker-checker o multinivel;
• selección de ruta y proveedor;
• autorización de firma;
• controles de liquidación y contabilización.

Cada paso debería crear una decisión estructurada: aprobar, retener, rechazar, escalar o anular. Las retenciones necesitan un responsable y un nivel de servicio. Las anulaciones requieren autoridad restringida, motivo, evidencia de apoyo y visibilidad independiente.

El valor predeterminado seguro es cerrar ante la ausencia de una decisión obligatoria. Esto no significa que toda advertencia técnica detenga todo proceso. Significa que los requisitos distinguen controles obligatorios de señales informativas y definen cómo afectan las dependencias degradadas a la transacción.

Las conclusiones jurídicas y regulatorias deben determinarse para la actividad, el instrumento, el tipo de cliente y la jurisdicción reales con asesoramiento jurídico cualificado y proveedores debidamente autorizados. Asset Haus proporciona infraestructura tecnológica y apoyo a la implementación; no presta servicios jurídicos, de custodia, corretaje, bolsa, colocación, asesoramiento fiscal ni asesoramiento de inversión.

Requisito 5: diseñe explícitamente la autoridad y las aprobaciones corporativas

Los flujos de banca minorista y corporativa no comparten el mismo modelo de autoridad. La tesorería corporativa puede requerir entidades, funciones, mandatos de firma, registros de beneficiarios, archivos por lotes, ventanas de pago, ejecución programada y aprobaciones multinivel.

La plataforma debería representar la autoridad como política, no como conocimiento operativo informal. Los requisitos deberían cubrir:

• funciones a nivel de entidad y cuenta;
• separación entre maker, checker, tesorería, cumplimiento y administración;
• autoridad delegada y vencimiento;
• límites por importe y activo;
• reglas de espera o aprobación para nuevos beneficiarios;
• aprobación de lotes y tratamiento de fallos parciales;
• revalidación en el momento de la ejecución;
• suspensión de emergencia y revocación de acceso.

Un escenario útil de aceptación es un lote corporativo programado en el que un beneficiario deja de ser elegible después de la aprobación pero antes de la ejecución. El sistema debería mostrar si se detiene todo el lote o solo el elemento afectado, si las aprobaciones siguen siendo válidas y cómo se registra el cambio en la pista de auditoría.

Requisito 6: concilie más de dos saldos

Las operaciones con activos digitales suelen exigir más que una comparación entre libro mayor y cartera. Según el diseño, la conciliación puede involucrar:

1. la posición visible para el cliente;
2. la posición en el sistema bancario central o libro mayor general;
3. la posición del proveedor de custodia o bóveda bancaria;
4. el registro de eventos de la red o del instrumento relevante.

Los requisitos deberían definir tiempos esperados, tolerancia, patas de activo y efectivo, elementos pendientes, comisiones, confirmaciones, reorganizaciones de cadena cuando correspondan, correcciones del proveedor y rupturas manuales.

Un control de conciliación solo es útil cuando una diferencia se convierte en un caso con responsable. Exija antigüedad, materialidad, enrutamiento, comentarios, evidencia, autoridad de resolución y criterios de cierre. Un estado verde diario sin población trazable ni registro de excepciones no es evidencia de aceptación.

Para valores tokenizados, añada el registro reconocido de titulares, las restricciones de transferencia, las acciones corporativas y los registros del administrador o agente de transferencia que requiera la estructura. Los flujos de transferencia controlada pueden incluir controles de elegibilidad, consentimientos, periodos de tenencia e integración con centros de negociación cuando corresponda; nunca deberían describirse como liquidez garantizada ni libre transmisibilidad.

Requisito 7: vincule la seguridad con las decisiones operativas

Los requisitos de seguridad deberían conectar los controles técnicos con las acciones que protegen.

Para claves y firma, defina:

• propiedad de claves y usos permitidos;
• módulo de seguridad de hardware u otro límite de seguridad;
• reglas de quórum y doble control;
• ceremonias de generación, rotación, copia, recuperación y destrucción;
• separación de entornos y redes;
• controles de acceso privilegiado;
• versionado de la política de firma;
• congelación de emergencia y pruebas de recuperación;
• registros de auditoría exportables.

Para la plataforma más amplia, defina federación de identidad, privilegio mínimo, segregación de funciones, gestión de secretos, cifrado, integridad de registros, gestión de vulnerabilidades, entrega segura de software, controles de dependencias, copias de seguridad, objetivos de recuperación y procedimientos de incidentes.

“Seguridad de nivel bancario” no es un criterio de aceptación. Un requisito mejor nombra el control, el responsable, la evidencia de configuración, la prueba, el resultado esperado y el umbral de remediación.

Requisito 8: haga arquitectónicas la residencia de datos y la observabilidad

La residencia de datos no se resuelve colocando una base de datos en una región preferida. Los requisitos deben identificar cada lugar al que pueden viajar datos de clientes, inversores, transacciones, documentos, claves, registros, soporte, copias y telemetría.

Cree un mapa de flujos de datos que incluya API de terceros, acceso de soporte, analítica, supervisión, recuperación ante desastres y sistemas de entrega de software. Marque qué datos pueden salir del perímetro del banco, cuáles deben tokenizarse o minimizarse y cuáles no deben salir.

La observabilidad necesita la misma disciplina. Operaciones debería poder responder:

• ¿Qué ocurrió con esta transacción?
• ¿Qué versión de política y datos tomó la decisión?
• ¿Quién la aprobó o anuló?
• ¿Qué proveedor y ruta se utilizaron?
• ¿Cuándo se reconoció la firmeza y se contabilizó en el banco?
• ¿Se concilió la posición?
• ¿Qué cambió después de un incidente o versión?

La respuesta debería provenir de evidencia vinculada, no de una reconstrucción manual entre paneles y correos electrónicos.

Requisito 9: preserve continuidad y cambio controlado

Una plataforma bancaria debe sobrevivir tanto a interrupciones de proveedores como a un cambio de proveedor tecnológico.

Los requisitos de continuidad deberían cubrir conmutación de proveedor, transacciones en cola, cotizaciones o saldos obsoletos, disponibilidad de firma, interrupciones del sistema central, conciliación tras la recuperación, comunicación al cliente y reanudación segura. La conmutación debe probarse con estados realistas, no solo con comprobaciones de salud de infraestructura.

La continuidad del proveedor también importa. Según el modelo, los requisitos pueden incluir acceso al código fuente, depósito en garantía, automatización del despliegue, exportación de configuración, portabilidad de datos, interfaces documentadas, manuales operativos y derechos para mantener un despliegue permitido. Estos controles no eliminan la necesidad de una propiedad interna competente, sino que la hacen verificable.

El control de cambios debería vincular cada versión con las políticas, integraciones y migraciones afectadas, los pasos de reversión, la evidencia de pruebas y las aprobaciones. Una actualización de cadena o proveedor puede cambiar supuestos de firmeza, comisiones, direcciones o firma aunque la interfaz del cliente parezca igual.

Requisito 10: divida la entrega por evidencia de aceptación

Un despliegue bancario creíble es una secuencia de alcances controlados, no una única fecha de lanzamiento.

Una secuencia práctica es:

1. Descubrimiento: perímetro del producto, sistemas, funciones, proveedores, datos y decisiones sin resolver.
2. Arquitectura: mapa de fuentes de verdad, estados de transacción, contratos de integración, zonas de seguridad y responsabilidad de controles.
3. Flujo principal: un activo y recorrido de cliente acotados a través de canales, decisiones, proveedor, liquidación, contabilización y conciliación.
4. Endurecimiento operativo: tratamiento de excepciones, informes, recuperación, rendimiento, pruebas de seguridad y manuales operativos.
5. Expansión: activos, redes, flujos corporativos, emisión o transferencias controladas adicionales solo después de aceptar la base.

Cada fase debería tener condiciones de entrada, entregables, evidencia de aceptación, responsables de decisión y una consecuencia para el fallo. La guía de puertas de evidencia para la entrega de tokenización muestra cómo estructurar esas puertas sin tratar una propuesta o informe de progreso como prueba de preparación. Está disponible en inglés.

Una matriz de evaluación de proveedores en 12 áreas

Puntúe a los proveedores por evidencia, no por la calidad de la presentación:

Área	Evidencia que debe solicitarse
Modelo operativo	Mapa de funciones y modelo de estados de transacción
Integración central	Contratos de mensajes y pruebas integrales de contabilización
Custodia y firma	Mapa de responsabilidad, política y escenario de interrupción
Cumplimiento	Cadena de decisiones, códigos de motivo y flujo de casos
Autoridad corporativa	Pruebas de funciones, mandatos, lotes y revalidación
Conciliación	Informe de diferencias multirregistro con cierre responsable
Seguridad	Matriz de controles y evidencia de pruebas independientes
Datos	Mapa completo de flujo, residencia, retención y acceso de soporte
Observabilidad	Paquete de evidencia de transacción y registros inmutables
Continuidad	Recuperación, conmutación, portabilidad y manuales
Entrega	Plan de aceptación por fases y registro de dependencias
Cambio	Proceso de versión, migración, reversión e impacto en políticas

Exija al proveedor que demuestre una transacción desde el inicio hasta la decisión, ruta, firma, liquidación, contabilización, conciliación y recuperación de auditoría. Después introduzca un fallo: tiempo de espera del proveedor, mensaje duplicado, cambio de estado del beneficiario, confirmación tardía de red o indisponibilidad del libro central. El camino de fallo revela más que una demostración pulida del camino feliz.

Preguntas frecuentes

¿Necesita un banco operar su propio sistema de custodia?

No necesariamente. La arquitectura puede utilizar un custodio externo debidamente autorizado, un límite de seguridad controlado por el banco o un modelo híbrido. El requisito es responsabilidad clara, control de políticas, integración, conciliación, continuidad y evidencia, no la propiedad de cada componente.

¿Debería la cadena de bloques ser la fuente de verdad?

No por defecto. El registro autoritativo depende del producto y del diseño jurídico-operativo. Un registro de red puede evidenciar eventos mientras el libro central, el registro reconocido de titulares u otro registro aprobado sigue siendo autoritativo.

¿Es obligatorio el despliegue local?

No de forma universal. Los despliegues controlados por el cliente, SaaS e híbridos tienen implicaciones operativas y de control diferentes. El banco debería elegir a partir de sus requisitos de datos, seguridad, resiliencia, inspección, integración y gestión del cambio, no de una etiqueta.

¿Cuál es el mejor primer caso de uso?

El mejor primer alcance prueba toda la cadena operativa con complejidad acotada: un segmento de clientes, activo o instrumento, ruta, patrón de proveedor y modelo contable. Debe ser suficientemente valioso para ejercitar controles reales y suficientemente limitado para diagnosticar fallos.

¿Cuándo está la plataforma lista para expandirse?

Cuando el flujo principal acotado tiene evidencia aceptada de autoridad, cumplimiento, seguridad, liquidación, contabilización, conciliación, operaciones, recuperación e informes. La disponibilidad de funciones no basta.

El estándar de decisión

Una plataforma bancaria de tokenización está lista para una evaluación seria cuando el equipo puede responder con evidencia a tres preguntas:

1. ¿Qué registros y decisiones permanecen bajo control del banco?
2. ¿Cómo viaja una transacción por todos los límites internos y externos, incluidos los estados de fallo?
3. ¿Qué demuestra que la posición, la contabilización, el permiso y la pista de auditoría resultantes son correctos?

Este estándar mantiene el token dentro del modelo operativo del banco en lugar de permitir que se convierta en un sistema separado con su propia verdad, controles y responsabilidad. Para equipos que preparan un taller acotado de arquitectura y requisitos, Asset Haus ofrece opciones de despliegue controladas por el cliente y una biblioteca pública de casos, ambas en inglés. La biblioteca ilustra contextos; no sustituye la diligencia ni demuestra que esta arquitectura bancaria exacta haya sido entregada.

Este artículo es educativo y se centra en el diseño operativo. No constituye asesoramiento jurídico, fiscal, regulatorio, de custodia, seguridad ni inversión. Los requisitos deben validarse para la institución, actividad, instrumento, tipo de cliente, entorno tecnológico y jurisdicción relevantes.