Saltar al contenido
Finance & Banking
Evolution Program
Inicio / modules / 20-tokenizacion-fx-onchain-y-mercados-programables / classes

Clase 05 · Ciclo de vida del instrumento

← 04 · Emisión: mercado primario tokenizado · Índice de la parte · 06 · Mercado secundario y liquidez prometida →

Parte 21 — Tokenización, FX on-chain y mercados programables · Nivel: Profesional — perfil bancario · Duración: 90 minutos

🎯 Propósito

Recorrer la vida del instrumento después de la emisión: cupones, amortizaciones, canjes, embargos y vencimiento. Es donde se rompen los proyectos, porque la emisión se prueba y el ciclo de vida se improvisa.

La emisión de la clase anterior es un día. Esta trata los años siguientes, que es donde fallan casi todos los diseños: cupones, opciones, embargos y amortizaciones que nadie modeló porque la emisión ya funcionaba.

📚 Objetivos

Al finalizar podrás:

  1. Enumerar los eventos del ciclo de vida y cuáles son programables.
  2. Diseñar el pago de un cupón con su fecha de corte y su reintento.
  3. Explicar por qué un embargo no puede programarse y qué se hace en su lugar.
  4. Calcular el efecto de un error en la fecha de corte.
  5. Especificar el procedimiento de vencimiento y destrucción del instrumento.

Agenda de 90 minutos

La clase dura noventa minutos y se recorre en cinco tramos. No es un horario rígido: es el orden en que los bloques de esta página se sostienen unos a otros, y por eso conviene respetarlo aunque cambien los tiempos.

Los diez primeros minutos se dedican a recuperar la clase anterior, porque casi todo lo que aquí se explica supone algo que ya se vio. Los veinticinco siguientes desarrollan los conceptos con la fuente oficial a la vista: las referencias del final de la página no son un adorno bibliográfico, se consultan mientras se estudia. Del minuto 35 al 55 se resuelve el ejemplo guiado paso a paso, sin saltarse ninguno, porque el error típico vive precisamente en el paso que parece obvio. Los veinticinco minutos siguientes son de práctica con datos propios o sintéticos —nunca reales de terceros—, que es cuando se comprueba si se entendió. Los diez últimos cierran con las preguntas de comprobación y el registro del entregable.

Si el tiempo aprieta, lo que se recorta es la práctica y se traslada al laboratorio de la parte; lo que no se recorta nunca es el ejemplo guiado.

🧩 Conceptos centrales

Los cuatro primeros términos son los eventos corporativos y su fecha; los cuatro siguientes, los casos difíciles y el final del instrumento. El embargo es el evento que ningún diseño automatiza bien: una orden judicial exige inmovilizar sin transferir, y eso no es un pago programado.

Concepto Comprensión verificable
evento corporativo Hecho que altera el instrumento o sus derechos
fecha de corte Momento que fija quién tiene derecho
evento obligatorio Se aplica a todos sin opción
evento con opción El tenedor elige entre alternativas
reintento Nuevo intento de un pago que falló
embargo Inmovilización ordenada por una autoridad
amortización parcial Devolución de parte del principal
destrucción Retirada definitiva del instrumento del registro

🧠 Modelo mental

El modelo mental es que la emisión se prueba y el ciclo de vida se improvisa. Un instrumento vive años y durante esos años hay pagos, opciones, embargos y amortizaciones, y casi todos los diseños se detienen en la emisión.

TRES FAMILIAS DE EVENTOS

  PROGRAMABLES POR COMPLETO
    cupón fijo, amortización a vencimiento,
    devengo de intereses
    → la condición es el calendario, y el
      calendario se conoce

  PROGRAMABLES CON DATO EXTERNO
    cupón variable, dividendo, canje por
    ratio de mercado
    → exigen un oráculo, y con él vuelven
      los problemas de la Parte 19, clase 9

  NO PROGRAMABLES
    embargo, orden judicial, sucesión,
    fusión, concurso del emisor
    → vienen de fuera del sistema y exigen
      una vía humana con autorización

EL ERROR TÍPICO ES DISEÑAR SOLO
LA PRIMERA FAMILIA.

📖 Desarrollo

1. El cupón, paso a paso

Pagar un cupón parece trivial y tiene cinco pasos, cada uno con su punto de fallo. El bloque los recorre en orden.

1 SE FIJA LA FECHA DE CORTE
    y se publica con antelación

2 SE CONGELA EL REGISTRO A ESA HORA
    o se toma una instantánea verificable
    (Parte 19, clase 4)

3 SE CALCULA EL IMPORTE POR TITULAR
    con la base de cálculo declarada

4 SE APROVISIONA EL DINERO
    y aquí está el primer punto de fallo:
    si el dinero no está, el contrato no
    puede pagar por mucho que esté programado

5 SE EJECUTA EL PAGO
    contra el registro de la instantánea

6 SE REGISTRAN LOS FALLOS
    titulares no localizables, cuentas
    bloqueadas, importes por debajo del mínimo

7 SE REINTENTA
    con un calendario declarado y un límite

8 SE CONSIGNA LO NO COBRADO
    según el procedimiento del emisor

2. Por qué la fecha de corte es crítica

Entre la fecha de corte y el pago el instrumento sigue cambiando de manos, y el precio tiene que reflejarlo. El bloque explica qué ocurre si el registro no marca esa diferencia.

ENTRE LA FECHA DE CORTE Y EL PAGO
EL INSTRUMENTO SIGUE NEGOCIÁNDOSE

  quien compra después del corte
  NO cobra ese cupón
  → el precio debe reflejarlo

SI EL REGISTRO NO MARCA ESA DIFERENCIA
  el comprador cree que compra con cupón
  y recibe un instrumento sin él

QUÉ EXIGE EL DISEÑO
  · marcar el instrumento como «sin cupón»
    entre el corte y el pago
  · publicar el corte con antelación suficiente
  · que la plataforma muestre ambos precios

Y SI HAY DOS REGISTROS (clase 2),
la fecha de corte debe tomarse en el de
referencia, no en el que sea más cómodo.

3. Lo que no se puede programar

Un embargo no se puede programar porque no cumple ninguna de las condiciones que exige una condición automática. El bloque las repasa y describe lo que se diseña en su lugar.

UN EMBARGO ES UNA ORDEN DE UNA AUTORIDAD
SOBRE UN TITULAR CONCRETO

  · no se conoce de antemano
  · no tiene una condición verificable en
    el registro
  · su alcance lo determina un tercero
  · puede ser parcial, temporal o condicional

LO QUE SE DISEÑA EN SU LUGAR

  una FUNCIÓN DE INMOVILIZACIÓN
  · activable solo por una función designada
  · con doble aprobación
  · que solo INMOVILIZA: no transfiere
    ni altera saldos
  · con registro inmutable del quién,
    cuándo y en virtud de qué

ES EL INTERRUPTOR DE LA PARTE 19, CLASE 8,
aplicado a un titular en vez de al contrato.

4. Eventos con opción

Algunos eventos exigen que el tenedor elija, y eso convierte el proceso en un problema de recogida de instrucciones. El bloque plantea la dificultad y el diseño que la resuelve.

EL TENEDOR ELIGE: CANJE, SUSCRIPCIÓN
PREFERENTE, COBRO EN EFECTIVO O EN TÍTULOS

  PROBLEMA
    hay que recoger la instrucción de miles
    de tenedores en un plazo, y aplicar
    una opción por defecto a quien no responda

  DISEÑO
    · plazo declarado y recordatorios
    · opción por defecto explícita en el folleto
    · instrucción revocable hasta el cierre
    · publicación del recuento antes de ejecutar

  RIESGO ESPECÍFICO DEL FRACCIONAMIENTO
    una opción que exige unidades enteras
    deja fuera a quien tiene fracciones
    → hay que decidir qué pasa con ellas
      ANTES, no cuando ocurra

5. Vencimiento y destrucción

El vencimiento cierra el ciclo con cuatro pasos que hay que ejecutar en orden. El bloque los enumera y recoge los tres errores que se cometen con más frecuencia.

AL VENCIMIENTO

  1 se paga el principal y el último cupón
  2 se marca el instrumento como vencido
  3 se destruyen las unidades
  4 se conserva el registro histórico
     durante el plazo legal

QUÉ SE HACE MAL CON FRECUENCIA
  · destruir las unidades antes de confirmar
    el pago → el tenedor se queda sin nada
  · no destruirlas → siguen negociándose
    unidades de un instrumento que ya no existe
  · borrar el registro histórico → se pierde
    la trazabilidad exigida

ORDEN CORRECTO
  pago confirmado → marcado → destrucción
  y nunca al revés

🧮 Ejemplo guiado

El ejemplo procesa varios eventos corporativos sobre el mismo instrumento, incluido un embargo. Conviene fijarse en el evento con opción: exige recoger la decisión de cada tenedor en un plazo.

Situación. Un bono tokenizado de 30 000 000 paga cupón semestral del 6,4 % anual. Hay que ejecutar el segundo cupón, con incidencias.

DATOS
  nominal vivo                   30 000 000
  cupón anual                          6,4 %
  periodicidad                     semestral
  titulares                            4 120
  fecha de corte             día 178, 18:00
  fecha de pago              día 182
  titulares con cuenta bloqueada          37
  titulares no localizables               14
  importe mínimo de pago                   1

Paso 1 — calcula el cupón total.

CUPÓN SEMESTRAL
  30 000 000 × 6,4 % / 2 = 960 000

POR UNIDAD (30 000 unidades de 1 000)
  960 000 / 30 000 = 32 por unidad

Paso 2 — mide el efecto de un error de una hora en el corte.

SUPUESTO · SE TOMA LA INSTANTÁNEA A LAS 19:00
EN VEZ DE LAS 18:00

  operaciones en esa hora: 46
  volumen: 214 unidades

  CONSECUENCIA
  46 pares de titulares con el cobro cambiado
  importe afectado: 214 × 32 = 6 848

  ¿ES POCO? El importe sí.
  El problema no es el importe: es que
  46 tenedores recibieron lo que no les
  correspondía y 46 no recibieron lo suyo,
  y corregirlo exige recuperar dinero ya pagado.

COSTE DE CORRECCIÓN
  supuesto: 92 gestiones × 85 = 7 820
  → MÁS QUE EL IMPORTE EN DISPUTA

Paso 3 — aprovisiona y detecta el fallo previo.

DINERO APROVISIONADO POR EL EMISOR
  955 000

NECESARIO
  960 000

  FALTAN 5 000

QUÉ HACE UN CONTRATO BIEN DISEÑADO
  · comprueba el aprovisionamiento ANTES
    de empezar a pagar
  · si no alcanza, NO PAGA A NADIE
    y emite una alerta

QUÉ HACE UNO MAL DISEÑADO
  · empieza a pagar por orden y se queda
    sin fondos a mitad
  → 156 titulares cobran y 3 964 no,
    sin ningún criterio

ES EL MISMO PRINCIPIO DE LA PARTE 20,
CLASE 5: el orden de llegada no reparte,
discrimina.

Paso 4 — ejecuta con el aprovisionamiento corregido.

APROVISIONADO 960 000

  titulares que cobran: 4 120 − 37 − 14 = 4 069
  importe pagado: supuesto 946 300

  pendiente por cuentas bloqueadas: 9 100
  pendiente por no localizables:     4 600
  TOTAL PENDIENTE: 13 700

Paso 5 — diseña el reintento.

CALENDARIO DE REINTENTO DECLARADO

  cuentas bloqueadas
    reintento a los 5, 15 y 30 días
    tras el desbloqueo, pago inmediato

  no localizables
    notificación por los canales declarados
    conservación del importe durante el
    plazo legal
    consignación al vencer ese plazo

LO QUE NO SE HACE
  · reintentar indefinidamente y de forma
    automática, porque cada intento fallido
    tiene coste y ruido
  · devolver el importe al emisor sin plazo,
    porque el derecho del tenedor subsiste

Paso 6 — resuelve un embargo llegado el día 180.

ORDEN JUDICIAL SOBRE UN TITULAR CON
1 200 UNIDADES, RECIBIDA EL DÍA 180

  la fecha de corte fue el 178:
  ese titular TIENE derecho al cupón

  PROCEDIMIENTO
  1 la función designada inmoviliza las
    1 200 unidades, con doble aprobación
  2 el cupón correspondiente (38 400)
    NO se paga al titular: se consigna
    a disposición de la autoridad
  3 se registra el quién, cuándo y en virtud
    de qué
  4 se comunica al titular

LO QUE NO SE HACE
  · transferir las unidades a nadie
  · anular el derecho al cupón
  · aplicar el embargo antes de recibirlo
    por el cauce formal

Paso 7 — comprueba el orden en el vencimiento.

SIMULACIÓN DEL VENCIMIENTO

  1 aprovisionar 30 000 000 + último cupón
  2 verificar aprovisionamiento completo
  3 tomar instantánea a la fecha de corte
  4 pagar
  5 CONFIRMAR el pago de cada titular
  6 marcar el instrumento como vencido
  7 destruir SOLO las unidades cuyo pago
    está confirmado
  8 mantener vivas las de pagos pendientes
    hasta resolverlos

EL PASO 7 ES EL QUE SE HACE MAL:
destruir todas a la vez deja sin instrumento
a quien todavía no ha cobrado, y con él
sin prueba de su derecho.

Interpreta: el error de una hora en la fecha de corte costó más corregirlo que el importe en disputa, y el aprovisionamiento insuficiente habría dividido a los tenedores en dos grupos sin ningún criterio. La emisión se prueba y el ciclo de vida se improvisa, y es en el ciclo de vida donde vive el riesgo.

🧭 Perspectivas

El ciclo de vida afecta a cada participante de forma distinta. La tabla lo recoge.

Actor Qué ve Qué decide
Cliente Un cupón que llega o no Si reclama
Inversionista Precio con o sin cupón Cuándo compra
Emisor Un pago que ejecutar Cómo aprovisiona
Agente de pagos Incidencias por resolver Qué reintenta
Custodio Instrucciones de eventos con opción Cómo las recoge
Plataforma Instantánea y ejecución Cómo la verifica
Autoridad Un embargo que ejecutar Sobre qué registro
Supervisor Un evento mal aplicado Qué exige corregir
Auditor Trazabilidad del pago Qué muestrea
Sociedad Derechos que se cumplen Qué certeza espera

🏦 Del cliente al banco

El tenedor espera cobrar un cupón y el sistema tiene que ejecutar un evento con fecha de corte. La tabla enfrenta las dos lecturas.

Vista del cliente Vista del banco Parte
«No me llegó el cupón» Cuenta bloqueada, con reintento programado 21, clase 5
«Compré antes del pago» Después del corte: el cupón no era suyo 21, clase 5
«Es automático, no falla» Falla si el emisor no aprovisiona 21, clase 5

⚖️ Riesgos y controles

Los riesgos son de eventos no previstos y de reintentos. La tabla los recoge con su control.

Riesgo Cómo se materializa Control
Fecha de corte errónea Cobra quien no debía Instantánea verificable y publicada
Aprovisionamiento insuficiente Se paga a unos y a otros no Verificar antes de empezar a pagar
Embargo aplicado mal Se transfiere o se anula un derecho Función que solo inmoviliza
Opción sin defecto declarado Quien no responde queda indefinido Opción por defecto en el folleto
Destrucción anticipada El tenedor pierde la prueba de su derecho Destruir solo lo pagado y confirmado
Reintento indefinido Coste y ruido crecientes Calendario declarado con límite

🧪 Práctica

El laboratorio pide procesar un año de eventos corporativos. El embargo y el evento con opción son los que deciden el ejercicio.

En labs/lab-02.md:

  1. Implementa el pago de cupón con instantánea y verificación previa.
  2. Provoca un aprovisionamiento insuficiente y comprueba que no paga a nadie.
  3. Aplica un embargo con la función de inmovilización y su registro.
  4. Ejecuta el vencimiento con destrucción solo de lo confirmado.

⚠️ Errores frecuentes

Los síntomas de la tabla describen eventos mal procesados. La causa es haber diseñado solo la emisión.

Síntoma Causa probable Corrección
Diseñar solo lo programable Es lo que se puede probar Los eventos de fuera son los que rompen
Pagar sin verificar fondos El contrato «ya paga» Verificar antes de empezar
Corte tomado donde conviene Hay dos registros Se toma en el de referencia
Programar el embargo Se busca automatizarlo todo Solo se diseña la inmovilización
Destruir todo al vencer Es lo ordenado Solo lo pagado y confirmado
Sin opción por defecto Se asume que todos responden La mayoría no responde

❓ Preguntas de comprobación

  1. ¿Cuáles son las tres familias de eventos y cuál se diseña peor?
  2. ¿Por qué la fecha de corte necesita marcar el instrumento como sin cupón?
  3. ¿Qué se diseña en lugar de programar un embargo?
  4. ¿Por qué hay que verificar el aprovisionamiento antes de pagar?
  5. ¿Cuál es el orden correcto de vencimiento y por qué importa el paso 7?

📥 Entregable

Guarda en portfolio/parte-21/clase-05/:

🔗 Referencias cruzadas

🔐 Seguridad, ética y límites

Trabaja siempre con datos sintéticos o propios: nunca uses datos reales de terceros, números de cuenta, documentos de identidad ni antecedentes crediticios ajenos. Este material es formativo y no constituye asesoría financiera, tributaria ni legal; las tasas, comisiones, límites y normas citados cambian y deben verificarse en la fuente oficial vigente del país donde se aplique. Cuando un cálculo alimente una decisión que afecte a otra persona, registra los supuestos y quién los aprobó.

📗 Fuentes y verificación


Anterior Índice Siguiente
← 04 · Emisión: mercado primario tokenizado Parte 21 · Programa 06 · Mercado secundario y liquidez prometida →