Currency Codes in XML Schema

Separate amount from currency

A monetary value has an amount and a currency identifier. Model them as separate values so decimal arithmetic and code-list validation remain explicit. Do not put a currency symbol inside the decimal text because symbols are locale-dependent and sometimes shared by several currencies.

Use stable code identifiers

Three-letter currency identifiers are commonly exchanged according to ISO 4217. A simple lexical restriction can require three uppercase ASCII letters, while a separately governed code-list layer verifies whether the identifier is currently assigned for the application’s effective date.

Avoid a permanently frozen enumeration

Embedding every known code as xs:enumeration provides strict validation but couples every code-list update to an XSD release. That may be correct for a versioned regulatory message. For systems that need independent code-list updates, use Schematron, an application registry or a generated schema artifact with its own release record.

Model decimal constraints carefully

xs:decimal represents exact decimal values, but fraction-digit rules differ across currencies and business contexts. Some codes use zero, two or three minor-unit digits, and cash rounding can differ from accounting precision. Apply those rules using the selected code-list version.

Test semantic edge cases

Tests should include negative values where refunds are permitted, zero, large amounts, currencies with different minor units, obsolete codes and an unknown code. State whether values are rounded, rejected or preserved when a consumer lacks the relevant code-list release.

Implementation notes

Represent a monetary amount as an exact decimal plus a separate currency code. Decide whether the contract stores major units, minor units or another quantity and state rounding behavior at every boundary. A schema can constrain lexical decimal form, but application or rule validation usually needs the selected currency to determine allowed scale and cash-rounding behavior.

Treat the currency list as versioned reference data. A three-uppercase-letter XSD pattern verifies shape, not assignment or validity on a transaction date. Systems with frozen regulatory releases may generate an enumeration into each schema version; systems needing independent updates can validate through a controlled registry or Schematron rule tied to an effective date.

Failure modes

Binary floating-point types can introduce rounding differences in values that must remain exact. Locale-formatted input can confuse decimal separators and grouping characters. Parse a defined exchange lexical form, retain the original value when audit requirements demand it and perform arithmetic with decimal types and an explicit rounding mode.

Currency symbols are unsuitable identifiers: the same symbol can represent several currencies, and presentation varies by locale. Obsolete or redenominated codes also require policy rather than silent substitution. Report unknown, inactive and incorrectly scaled values distinctly so operators can choose whether to reject or investigate them.

Review checklist

• Amount and code separated
• Decimal arithmetic used
• Code-list release identified
• Scale rules currency-aware
• Rounding mode explicit
• Obsolete codes tested

Questions for a design review

Use this reference to make a review decision, not merely to recognize terminology. Record the concrete document, schema, processor or consumer being discussed; the language and processor versions; and the behavior that must remain compatible. A useful review produces fixtures and an owner for every unresolved assumption.

• What executable example or test demonstrates the intended behavior for separate amount from currency?
• What executable example or test demonstrates the intended behavior for use stable code identifiers?
• What executable example or test demonstrates the intended behavior for avoid a permanently frozen enumeration?
• What executable example or test demonstrates the intended behavior for model decimal constraints carefully?
• What executable example or test demonstrates the intended behavior for test semantic edge cases?

Include at least one ordinary case, one boundary case and one deliberately invalid or unsupported case. Check the result in the actual production toolchain, because parsers, validators, code generators and reasoners do not all implement the same optional features. Store the selected contract version with the test result, then repeat the review when a dependency, namespace, profile or public declaration changes.

Continue with a working reference

XML Schema tutorial · Code-list checks with Schematron