Infraestructura B2B para activos reales: una arquitectura por módulos

Las organizaciones que estructuran activos e instrumentos tienen que hacer varias cosas a la vez: comunicar, identificar a las personas y a quienes las representan, conservar documentos, registrar derechos, llevar la contabilidad de cada movimiento y relacionarse con entidades autorizadas. Cuando todas esas funciones viven en el mismo sistema, un fallo en una de ellas puede arrastrar a las demás, y cualquier cambio se vuelve costoso. Una arquitectura por módulos parte de la idea contraria: cada función tiene su frontera, sus permisos y su responsable.

Funciones distintas, fronteras claras

• Web pública: informa y orienta. No necesita, ni debería tener, acceso a los datos económicos o personales del núcleo.
• Gestión de contenidos: edita textos e imágenes con sus propios usuarios y permisos, separados de los operativos.
• Identidad y representación: acredita personas, organizaciones, poderes y capacidades efectivas.
• Expediente documental: conserva los documentos con control de versiones y huellas de integridad.
• Núcleo de derechos y libro contable: registra instrumentos, posiciones y movimientos económicos en doble partida.
• Conectores externos: pagos, custodia, firma, registro y redes DLT, a través de adaptadores sustituibles.

Por qué separar

La separación tiene tres efectos prácticos. Limita el alcance de un incidente: si la web pública sufre un problema, el registro de derechos no debería verse afectado. Permite asignar permisos mínimos: quien edita un artículo no necesita, ni debe, poder aprobar un movimiento económico. Y facilita la auditoría, porque cada pieza deja su propio rastro y responde ante un responsable identificado.

El núcleo no depende del token ni de la red

El activo y el instrumento jurídico son la referencia; la representación digital es una capa posterior. Si el núcleo depende de una red concreta, un cambio de estándar, de proveedor o de régimen jurídico obliga a rehacer los derechos registrados. Si la red se conecta mediante un adaptador, la cadena puede cambiar sin que cambie quién es titular de qué. Es el mismo principio que separa el registro de autoridad de las observaciones que se leen de una cadena.

Construir lo propio y apoyarse en entidades autorizadas para lo regulado

No todas las piezas deben construirse. La verificación de identidad, la custodia, los servicios de pago o la firma electrónica cualificada son actividades especializadas y, en muchos casos, reguladas. Un diseño prudente se apoya en entidades autorizadas para ellas y concentra el desarrollo propio en lo que distingue a la plataforma: el modelo de activos e instrumentos, el expediente, el registro de derechos y la contabilidad. Así se evita asumir por accidente actividades que requieren autorización.

Varias organizaciones sobre un mismo núcleo

Una infraestructura con vocación B2B tiene que servir a varias organizaciones sin mezclar sus datos. Eso exige segregación por organización en la propia capa de datos, no solo en la interfaz; permisos que combinen persona, organización, capacidad y acción; doble control para las operaciones económicas sensibles; y políticas por jurisdicción que bloqueen por defecto lo que no se haya habilitado expresamente, conservando la versión de la política aplicada en cada decisión.

Portabilidad y continuidad

Una organización debe poder llevarse su infraestructura a otro proveedor sin perder datos ni control. Eso se traduce en decisiones concretas:

• Despliegues reproducibles descritos como código, no configurados a mano.
• Configuración y secretos fuera del código fuente.
• Datos separados de las aplicaciones, con copias de seguridad fuera de la máquina que los aloja.
• Componentes estándar y sustituibles, sin dependencias accidentales de un único proveedor.
• Una prueba de migración completa antes de dar por buena la arquitectura.

Resiliencia operativa y DORA

En el sector financiero europeo, el Reglamento (UE) 2022/2554, conocido como DORA, exige a las entidades financieras gestionar el riesgo tecnológico, notificar los incidentes graves, probar su resiliencia operativa y controlar a sus proveedores de servicios TIC, y prevé un marco de supervisión para los proveedores considerados críticos. Su aplicación depende de quién sea la entidad y de qué servicio preste, y debe evaluarse en cada caso. Aun cuando no se aplique directamente, sus principios son una referencia útil para diseñar una infraestructura que otras entidades puedan necesitar evaluar.

Las modalidades de servicio B2B son una visión de producto. Su disponibilidad dependerá de las capacidades efectivamente desplegadas, de los acuerdos aplicables y de las autorizaciones que correspondan en cada caso.

Qué preguntar a un proveedor de infraestructura

• Qué funciones presta directamente, cuáles delega en entidades autorizadas y cuáles son esas entidades.
• Dónde se registra la titularidad de cada derecho y qué registro prevalece si hay discrepancias.
• Cómo se separan los datos de cada organización y quién puede acceder a ellos.
• Qué datos personales se tratan, dónde se alojan y quién actúa como responsable del tratamiento.
• Cómo se recuperaría el servicio tras un incidente y con qué frecuencia se prueba esa recuperación.
• Cómo podrías migrar tus datos y procesos a otro proveedor si lo necesitaras.

Bridge Positive aplica estos principios de forma progresiva. En su entorno de laboratorio ya separa los datos de cada organización en la propia base de datos, combina persona, organización y capacidad en los permisos, registra instrumentos, posiciones y movimientos de unidades en un libro de doble partida que solo admite nuevas anotaciones, y exige una segunda persona en las aprobaciones principales. Otros principios de este artículo —conectores con redes DLT y servicios externos, políticas por jurisdicción, despliegues descritos como código, copias de seguridad fuera del servidor y una prueba completa de migración— forman parte de la hoja de ruta técnica de la plataforma. Si representas a una organización y quieres conocer el enfoque, la página de empresas reúne la visión de colaboración.

Nota editorial: Información general sobre arquitectura tecnológica, no asesoramiento. Describe principios de diseño de la plataforma, no servicios disponibles ni contratables hoy.

← Volver al blogMás artículos de Empresas