Summary

  • draft-ietf-regext-balance-02 gives an authenticated EPP client a standard way to query balance available, credit line, cash balance and optional execution and notification thresholds.
  • The response can explain the amount visible to the client, including optional currency components, but it does not expose the transaction ledger, calculation time, exchange-rate provenance, policy version or reserved obligations behind that amount.
  • When the balance affects whether a billable command proceeds, registry operators and registrars need a separate funding-state receipt that binds the response, governing policy and later command outcome without turning EPP into a general accounting protocol.

Imagine a registrar beginning a renewal batch just before a holiday. Its EPP session reports a positive balance available. Minutes later, one renewal succeeds and the next one is rejected. Support can see the number the registrar saw. Finance can see a private ledger. Operations can see two transaction identifiers. None of those records necessarily proves which debits, reservations, exchange rate or threshold policy governed the rejected command.

That is not a defect in arithmetic. It is a boundary between an operational protocol and the accounting system behind it.

The REGEXT working group’s balance mapping is designed to make one part of that boundary more consistent. Revision 02, posted on 14 August 2026, defines an EPP extension through which the currently logged-in client can retrieve its financial state. The draft is active work intended for the Standards Track; it is not yet an RFC, and its publication does not establish that any particular registry has deployed it.

Its value is easy to see. Registrars should not need a proprietary portal, an email alert and a registry-specific vocabulary merely to determine whether prepaid funds or credit remain available. But standardizing the visible number also raises a governance question: what exactly can that number prove after it has influenced a transaction?

A calculated gate, not a bank statement

The central quantity is balanceAvailable. The draft defines it as creditLine + cashBalance. Cash balance represents funds held by the server operator for the client. Credit line represents the amount of credit the operator extends. A charge reduces the balance and is represented as a negative value; a refund or deposit is positive; a withdrawal is negative.

This is more disciplined than an unlabeled “account balance.” It tells software which components make the displayed spending capacity. It also avoids using balance outstanding, a different accounting concept that can describe what the client owes after credit is considered.

Yet the response is a state projection, not a ledger. The schema does not enumerate the purchases, refunds, deposits, withdrawals or adjustments that produced cash balance. It does not say when the calculation became true, which accounting period is closed, whether a disputed charge remains included or which pending activity has been reserved but not posted. A client can learn the value the registry currently exposes without being able to independently reconstruct it.

That distinction matters only when the number does work. A dashboard number can be advisory. A value that governs renewal, transfer or creation capacity is part of the control plane of a registrar’s business, even if it lives in a financial extension rather than a domain object command.

The limit changes the meaning of “available”

An optional executionLimit determines the point below which billable client transactions may be denied. Its default is 0.00, but the draft deliberately permits both positive and negative values.

A positive execution limit creates a reserve above zero. The draft gives server-initiated activity such as auto-renewals as the reason an operator might keep that safety margin. The client can have money showing as available and still lack enough room for a new billable command because the operator has protected capacity for obligations that may arise without a fresh client request.

A negative limit has the opposite effect. It lets the client initiate additional billable transactions after balance available passes below zero, effectively extending the usable operational boundary. The economic meaning is therefore not contained in balanceAvailable alone. It emerges from the balance, the limit and the amount of the contemplated transaction.

The protocol exposes the current limit, which is valuable. It does not expose the policy that set it: who approved the margin, when it changed, whether it differs by product, how auto-renew exposure was estimated, or which exception applies during an incident. A dispute may consequently become a comparison of screenshots rather than an examination of the rule actually executed.

Nor does a successful balance query guarantee that a later command will succeed. Money may change, another session may submit work, a registry may apply product-specific rules, or a non-financial policy may reject the command. The mapping supplies an input to a decision. It is not a reservation and not an authorization token.

A warning is a queue event, not a reconciliation

The optional notificationThreshold lets the server create a low-balance message when the relevant amount crosses a configured point. The threshold’s basedOn attribute must use the same basis as the execution limit, preventing one control from speaking about cash balance while the other silently governs balance available.

The notification uses EPP’s existing poll queue. Under the base protocol, the response includes queue metadata such as the enqueue date and server message identifier, while the command and response carry client and server transaction identifiers. The client acknowledges the message through the ordinary poll lifecycle. The balance draft specifies a single notification when the threshold is crossed rather than a flood on every subsequent query.

That makes the alert operationally manageable. It still does not reconcile the account. A poll message can prove that the server placed a warning in the queue and that the client later acknowledged it. It cannot, by itself, prove which line items drove the crossing, whether the warning preceded a specific batch, or whether the threshold changed between the warning and the refusal.

Queue acknowledgement is especially easy to overread. It demonstrates receipt by the EPP client, not comprehension by a finance team, correction of a funding shortfall or consent to the registry’s calculation. Good operational evidence keeps those propositions separate.

Currency detail exposes a calculation without its provenance

Multi-currency operation makes the boundary sharper. The draft permits cash to be decomposed into components with a currency, an amount, a conversion rate and a value converted into the reference currency. Those converted values must sum to the reported cash balance. The rate follows direct quotation: one unit of the component currency multiplied by the rate yields the reference-currency amount.

This is enough for a client to check the arithmetic of the presented conversion. If one account holds euros and dollars while the registry operates in another reference currency, the client can see how the components were rolled up instead of receiving an unexplained aggregate.

But the response does not name the rate provider, the observation timestamp, the pricing convention beyond direct quotation, a rounding policy version or a fallback used during market-data failure. It contains no explicit balance-as-of time. Two perfectly formatted responses can therefore reflect different economic moments while remaining impossible to distinguish from schema alone.

ISO 4217 codes make the units interoperable. They do not make the rate contestable. In volatile markets, or around a batch large enough to approach the execution limit, provenance can decide whether a client had room to act. A converted amount is evidence of a calculation; without source and time, it is weak evidence of why that calculation was authoritative.

The currency-mismatch-infrastructure issue is not that EPP should become a foreign-exchange platform. It is that infrastructure decisions inherit hidden dependencies when money is normalized across currencies. The more consequential the gate, the more important it is to retain those dependencies outside the wire response.

Confidentiality narrows who can audit

The draft treats balance information as confidential and limits access to the currently logged-in client. That is the right default: one registrar should not be able to query another registrar’s funding position, credit line or threshold.

The same access boundary can complicate post-incident review. A support engineer may see the EPP transcript but not the accounting adjustments. Finance may see ledger entries but not the exact session and command sequence. A managed service may operate the registrar connection while the contracting entity funds the account. If each party retains only its own slice, no one can bind the financial state to the operational decision without assembling sensitive systems after the fact.

The solution is not to make balances public or to replicate the full ledger into EPP. It is to design a narrow receipt whose fields are sufficient for reconstruction and whose access follows the commercial relationship. Confidentiality and accountability are not opposites; the receipt should disclose less than a ledger while proving more than a screenshot.

Record the funding state that actually governed the command

I propose a funding-state receipt whenever a balance-related rule materially warns about, permits or denies a billable EPP command. This is an editorial governance proposal, not a requirement in the Internet-Draft.

The receipt should bind the authenticated client identity, EPP session or security context, balance-response clTRID and svTRID, retrieval time, reference currency, balance available, cash balance, credit line, execution limit and notification threshold. Where multiple currencies contribute, it should retain each amount, applied rate, rate source, rate observation time and rounding policy.

It should also identify the calculation basis that EPP does not carry: ledger snapshot or immutable statement reference, material pending debits and credits, reserved auto-renew exposure, policy version and any temporary exception. The record need not copy every commercial line item. A hash or controlled reference can preserve integrity while keeping detailed accounts in the system authorized to hold them.

Finally, the receipt should bind the attempted command: object class, charge basis or fee reference, requested time, decision time, outcome, applicable EPP result code and the command’s client and server transaction identifiers. If a non-financial rule caused rejection, the record should say so. If the balance changed between query and command, both states should be retained rather than overwriting the earlier one.

This turns a vague claim—“you had insufficient funds”—into a falsifiable sequence. The registrar can determine what it knew, the registry can demonstrate which rule it ran, and both can identify whether the difference came from timing, currency conversion, reservation policy, concurrency or accounting correction.

Do not ask the extension to prove what it never promised

The mapping is deliberately query-only. It defines no balance-specific behavior for EPP check, create, delete, renew, transfer or update commands. That keeps the extension composable and avoids pretending that every registry product follows the same charging model.

The boundary should remain. Embedding a full invoice, exchange-rate service or reservation engine in the extension would make adoption harder and expose more confidential detail than routine automation needs. Protocol minimalism is useful when the surrounding accountability mechanism is explicit.

The risk is institutional, not syntactic. Once a standard field is widely consumed, it may become the number that support teams, automation and customers treat as definitive. If the evidence behind it remains proprietary and ephemeral, standardization can make the surface uniform while leaving the reasons for consequential differences opaque.

Revision 02 improves the vocabulary: it renamed the central field from balance to balance available, added basedOn and advanced the namespace to version 0.3. Those changes show why careful names matter. “Available” signals that the number belongs to an operational decision, not merely an account statement. The next governance step is to make the decision’s provenance equally legible.

An EPP balance can tell a registrar what the registry is prepared to expose now. A funding-state receipt should explain, later, why that state was allowed to decide what happened next.

Sources