Resumen

  • draft-ietf-regext-balance-02 crea una consulta común para que el cliente EPP autenticado conozca saldo disponible, efectivo, línea de crédito y límites opcionales de ejecución y aviso.
  • Esos campos describen una capacidad operativa, no el libro de movimientos: faltan la hora efectiva del cálculo, el origen del tipo de cambio, la versión de la política, las reservas y las partidas que componen el saldo.
  • Si la cifra condiciona una operación facturable, registro y registrador deberían conservar un recibo de estado financiero unido a la decisión y a sus identificadores EPP.

Un registrador prepara cientos de renovaciones. Consulta el saldo y recibe una respuesta positiva. La primera tanda entra; una orden posterior no. Desde fuera, parece una contradicción. Desde dentro, pueden haber cambiado los fondos, una reserva para autorrenovaciones, el límite aplicable o la conversión de moneda. El dato visible y la decisión son dos instantes distintos.

La propuesta del grupo REGEXT busca que el primero deje de depender de interfaces privadas. La revisión 02 apareció el 14 de agosto de 2026 como documento activo del grupo, con intención de avanzar por la vía de estándares. Sigue siendo un Internet-Draft: no es un RFC y no acredita por sí mismo que un registro concreto lo use en producción.

La extensión merece atención precisamente porque una consulta pequeña puede gobernar mucho. Al llevar el estado financiero a EPP, el mismo canal que aprovisiona dominios obtiene una señal estructurada sobre la capacidad de pagar. La interoperabilidad mejora; la pregunta de quién puede explicar un rechazo se vuelve más urgente.

La suma está definida; su historia, no

El borrador llama balanceAvailable a la suma de creditLine y cashBalance. La segunda cifra son fondos que el operador mantiene para el cliente; la primera es crédito que le concede. Los cargos restan y se expresan con signo negativo. Reembolsos y depósitos suman; los retiros vuelven a restar.

Estas convenciones eliminan varias ambigüedades frecuentes. También separan el saldo disponible del saldo pendiente, que responde a una pregunta contable distinta y no se utiliza en el mapeo.

Sin embargo, el XML no entrega las líneas del libro mayor. No aparecen cada alta, renovación, depósito, devolución o corrección que condujo al efectivo actual. Tampoco hay una marca explícita de «saldo a fecha de», una referencia al cierre contable, el estado de una partida impugnada o una relación de compromisos reservados.

Por eso la respuesta permite comprobar qué afirma el servidor, no reproducir el cálculo con independencia. No es una carencia sorprendente: EPP no pretende ser un sistema contable. El problema surge cuando una institución deja que esa proyección actúe como puerta de acceso y después la trata como explicación suficiente.

Un límite puede reservar o ampliar la capacidad

El executionLimit opcional fija el punto a partir del cual el servidor puede denegar transacciones facturables del cliente. Si no se declara, vale 0,00. Lo interesante es que puede ser positivo o negativo.

Un límite positivo retiene un colchón. El propio borrador menciona operaciones iniciadas por el servidor, como las autorrenovaciones. Aunque el cliente vea fondos por encima de cero, el operador puede impedir que los consuma en una orden nueva para proteger cargos que aún no han llegado.

Un límite negativo permite lo contrario: que el cliente siga operando algo por debajo de cero. Esa tolerancia equivale a una frontera operativa adicional, aunque no modifique la fórmula del saldo disponible.

Así, «tengo saldo» nunca basta para predecir el resultado. Hace falta conocer el límite y el precio de la acción. Aun así no existe garantía, porque otra sesión puede gastar, el estado puede variar o una regla ajena al dinero puede rechazar la orden.

El mapeo muestra el límite vigente, pero no su gobierno. No dice quién autorizó la reserva, qué cálculo de autorrenovaciones la sustenta, cuándo cambió, durante cuánto tiempo rige una excepción o si algunos productos tienen otra política. Dos clientes con la misma cifra visible podrían estar sometidos a decisiones diferentes sin que la respuesta explique la diferencia histórica.

El aviso demuestra entrega, no acuerdo

El notificationThreshold opcional permite insertar un mensaje de saldo bajo cuando la cantidad cruza el umbral. El atributo basedOn debe coincidir con la base del límite de ejecución. Es una salvaguarda útil: alerta y bloqueo no deberían hablar en silencio de magnitudes distintas.

El mensaje viaja por la cola de sondeo de EPP. El protocolo base aporta fecha de cola, identificador del mensaje y los identificadores de transacción del cliente y del servidor. Después, el cliente confirma la recepción mediante el ciclo normal de poll. El borrador evita avisos repetidos y propone uno al producirse el cruce.

Esa evidencia establece que el servidor emitió una alerta y que una aplicación la reconoció. No prueba que tesorería la leyera, que se ingresaran fondos, que el registrador aceptara el cálculo ni que el umbral siguiera intacto cuando llegó una orden posterior.

En gobernanza, reconocer un mensaje no equivale a aceptar una deuda. La distinción debe sobrevivir a los cuadros de mando que convierten la cola en una simple marca de «notificado».

El tipo de cambio es parte invisible de la puerta

La opción multimoneda desglosa el efectivo en componentes. Cada uno puede incluir moneda, importe, tipo de conversión y valor resultante en la moneda de referencia. La suma de los valores convertidos debe coincidir con cashBalance. La cotización es directa: la cantidad se multiplica por el tipo para obtener el valor de referencia.

Con ello, un registrador puede revisar la aritmética mostrada. Los códigos ISO 4217 reducen dudas sobre unidades. Lo que no puede revisar es la autoridad económica del tipo: el esquema no nombra proveedor, hora de observación, política de redondeo ni fuente alternativa usada durante una interrupción. Tampoco fija el momento exacto del saldo.

Lejos del límite, esa opacidad quizá no cambie una operación. Cerca de él, una pequeña diferencia decide si una tanda cabe o no. La infraestructura monetaria se incorpora entonces al control de nombres sin dejar una huella completa en la respuesta.

La solución no consiste en convertir EPP en un mercado de divisas. Consiste en conservar fuera de EPP la procedencia del dato que tuvo consecuencias dentro de EPP.

La confidencialidad exige una prueba más estrecha

El borrador considera confidencial la información financiera y restringe la consulta al cliente que ha iniciado sesión. Es una elección necesaria. El crédito y el efectivo de un registrador no deben quedar visibles para competidores o terceros.

Esa misma separación reparte la prueba. Operaciones conoce las sesiones; finanzas, los asientos; un proveedor técnico, la ejecución; el registro, la regla. Compartir el libro completo violaría el principio de mínimo acceso. Conservar solo la respuesta deja demasiado poco para una investigación.

Entre ambos extremos cabe un recibo con campos limitados, integridad verificable y acceso bilateral. Puede revelar menos información comercial que una cuenta detallada y, a la vez, explicar mejor qué estado decidió.

El recibo de estado financiero

Propongo que toda advertencia, autorización o denegación material basada en saldo genere un recibo de estado financiero. Es una propuesta editorial de gobernanza, no una obligación del borrador IETF.

El primer bloque uniría identidad autenticada, contexto de sesión, hora de consulta, clTRID, svTRID, moneda de referencia, saldo disponible, efectivo, crédito, límite de ejecución y umbral de aviso. Para cada moneda conservaría importe, tipo aplicado, fuente, hora de observación y regla de redondeo.

El segundo bloque apuntaría al fundamento privado: instantánea inmutable del libro o su hash, débitos y créditos pendientes relevantes, reserva para autorrenovaciones, versión de política y excepción temporal. No es necesario copiar todas las partidas al protocolo público; basta con que la organización no pueda reconstruirlas retrospectivamente a conveniencia.

El tercero fijaría la decisión: clase de objeto, referencia del precio, hora de solicitud, hora de resolución, resultado, código EPP y pares de identificadores. Si el motivo fue ajeno al saldo, debe constar. Si entre consulta y orden hubo un cambio, se guardan ambos estados.

El resultado no elimina disputas, pero las vuelve comprobables. Una diferencia puede atribuirse a concurrencia, reservas, conversión, contabilización tardía o política, en lugar de quedar reducida a «el sistema decía que no».

Minimalismo con memoria institucional

La extensión solo define una consulta. No añade comportamiento propio a check, create, delete, renew, transfer o update. Esa limitación es sensata: los modelos de cobro no son uniformes y un protocolo de aprovisionamiento no necesita transportar facturas enteras.

El riesgo aparece después de la adopción. Una cifra normalizada tiende a convertirse en la verdad que leen soporte, clientes y automatizaciones. Si los componentes que le dieron autoridad se borran, la uniformidad de la interfaz oculta la diversidad de reglas internas.

La revisión 02 ya afinó el nombre central de «balance» a «balance available», añadió basedOn y actualizó el espacio de nombres a 0.3. Es una buena señal: las palabras deben reflejar la función. «Disponible» describe una capacidad condicionada. El recibo propuesto conservaría las condiciones concretas que la hicieron operativa.

Fuentes